7 Bruk av Åpen-edi referansemodellen og OOram ved utvikling av interorganisatoriske systemer

7.1 Innledning

I dette kapitlet vil jeg skissere en systemutviklingsmetode basert på Åpen-edi referansemodell og OOram. Åpen-edi referansemodellen gir et rammeverk, og OOram benyttes som en formell beskrivelsesteknikk for å lage scenarier og interorganisatoriske systemer. Jeg vil se på fasene analyse og design, implementering og bruk. Med fasen implementering mener jeg koding og testing. Fasen bruk vil si at systemet brukes aktivt i henhold til sin intensjon. Faseinndelingen er i overensstemmelse med [DIS]. Grunnen til at det er interessant å se på alle fasen helt frem til systemet er tatt i bruk er at jeg da vil kunne vurdere hvordan Åpen-edi referansemodellen forholder seg til problemer som gjelder for dagens EDI, faktorer som påvirker utbredelse og om målene for Åpen-edi referansemodellen blir nådd. Denne vurderingen foretar jeg i kapittel ni. Tredje delmål var videreutvikle og konkretisere Åpen-edi referansemodellen, det gjøres i dette kapitlet.

Jeg vil presisere at et interorganisatorisk system er sammensatt av flere interne interorganisatoriske systemer, vanligvis et for hver EDI-aktør. (Definisjonene av interne interorganisatoriske systemer og interorganisatoriske systemer gjøres i avsnitt 1.7). Den fremgangsmåten jeg skisserer skal benyttes for å lage interne interorganisatoriske systemer som tar hensyn til helheten i det interorganisatoriske systemet.

Punkter fra oppsummering i kapittel to tas opp på følgende steder i dette kapittelet:

Problemer knyttet til hvordan EDIFACT-meldingstyper blir utviklet og at informasjon kan gå tapt når en konverterer til og fra EDIFACT-format-- Tas opp i fase en
Problemer knyttet til at virksomheter implementerer EDIFACT-meldingstyper forskjellig -- Tas opp i fase en
Problemer knyttet til jus og EDI -- Tas opp i fase en
Problemer knyttet til valg av målgruppe, utviklingsstrategi og versjonshåndtering for EDIFACT. -- Tas opp i fase to og tre

Punkter fra oppsummering i kapittel fire tas opp på følgende steder i dette kapittelet:

lover, regler og handelsavtaler -- tas opp i fase en og tre
problemer ved innføringen av EDI -- tas opp i fase tre
teknisk utstyr og datakommunikasjon -- tas opp i fase to
organisatorisk modenhet -- tas opp i fase to
kompleksitet i et interorganisatorisk system -- tas opp i fase to og tre
design og redesign av interorganisatoriske systemer -- tas opp i fase tre
kompatibilitet og kontekstavhengighet -- tas opp i fase en og tre
stabilitet og versjonshåndtering -- tas opp i fase en og tre
administrasjon og koordinering av interorganisatoriske systemer -- tas opp i fase en

Jeg vil i starten av dette kapitlet beskrive hvilke faser som må gjennomgås. Figur 19 angir sekvensen av disse fasene.

Figur 19
Pilene i Figur 19 viser bevegelsesretning for utviklingsprosessen. Jeg vil senere referere til Figur 19, da vil følgende miniatyr utgave bli vist:

Hver av de tre fasene er skissert i egne figurer. Første fase har jeg skissert i Figur 20 og Figur 21.

7.2 Analyse og design av scenarier

I dette avsnittet vil jeg beskrive hvordan analyse og design av scenarier foregår. Åpen-edi referansemodellen har skissert at scenarier skal modelleres i henhold til følgende begreper: Roller, informasjonspakker og scenarioattributter. Jeg vil dele denne fasen opp i to hoveddeler, en som ser på operativt virksomhetsperspektiv og en som ser på teknologisk tjenesteperspektiv. Resultatene fra denne fasen er beskrivelser av scenarier, og beskrivelser av teknologiske tjenester. Jeg vil bruke resultatene fra disse to hoveddelene i de senere fasene.

Først vil jeg se på operativt virksomhetsperspektiv. En brukergruppe benytter Åpen-edi referansemodellens krav til formelle beskrivelsesteknikker og andre krav, til å velge formell beskrivelsesteknikk. Brukergruppen kan være en bransjeorganisasjon, en gruppe virksomheter, representanter for offentlig virksomhet, standardiseringsorgan m.m. Brukergruppen benytter den valgte formelle beskrivelsesteknikken til å beskrive et scenario. Scenariobeskrivelsen bør være mest mulig generell for å unngå at en får mange nesten like scenarier. Denne scenariobeskrivelsen er ikke en beskrivelse av et konkret system, men i hovedsak en beskrivelse av grensesnitt mellom interne interorganisatoriske systemer og krav til denne type system. De ferdige beskrivelsene sendes til en registreringsautoritet som etter godkjenning legger beskrivelsen inn i operativt virksomhetsperspektiv scenario repository. Denne beskrivelsen vil senere bli brukt som bakgrunn for å utvikle teknologiske tjenester og til å automatisk generere interne interorganisatoriske systemer. Den enkelte EDI-aktør som skal bruke et interorganisatorisk system blir først involvert i neste fase.

Figur 20
Figur 20, notasjonsforklaring: Firkanter og databasemetaforer angir produkter og resultater. Ovale sirkler angir hvem som utfører aktiviteter.

Jeg foreslår å laget et repository for teknologisk tjenesteperspektiv som tillegg til det [DIS] foreslår. Årsaken er at jeg i de videre fasene ser behovet for referanselinjer når det gjelder hvordan de teknologiske tjenestene til det interorganisatoriske systemet skal implementeres. Det er nødvendig å skille mellom typebeskrivelsen av teknologiske tjenester, og produkter og tjenesteytere som realiserer de teknologiske tjenestene. En videreutviklet versjon av figur 4 i [DIS] er skissert i Figur 20, Figur21 og Figur 23. jeg kommer i denne oppgaven ikke til å gå inn på hvordan de teknologiske tjenestene beskrives. Mitt hovedfokus vil være operativt virksomhetsperspektiv, uavhengig av konkrete implementasjoner av tjenester og valg av programmeringsspråk.

Ved hjelp av formelle beskrivelsesteknikker vil en gruppe IT-designere benytte krav fra de beskrevne scenariene, kriterier fra Åpen-edi referansemodellen og internasjonale IT-standarder beskrive teknologiske tjenester. Disse beskrivelsene vil være teknologisk tjenesteperspektiv standarder. De legges i teknologisk tjenesteperspektiv-repository. Figur 21 viser dette forløpet.

De formelle beskrivelsene skal benyttes av programvareleverandører som utvikler programvarebiblioteker. Programvarebibliotekene skal igjen danne grunnlaget for generering av interne interorganisatoriske systemer. Både operativt virksomhetsperspektiv-repository og teknologisk tjenesteperspektiv-repository kan ses på som elementer for å lage en god referanselinje for første fase.

Figur 21

7.2.1 Scenario

Åpen-edi referansemodellen bruker scenariobegrepet som beskrivelsen av en forretningstransaksjon. Et scenario beskrives ved bruk av roller, informasjonspakker, og scenarioattributter. I følge [DIS] vil deler av et scenario være valgfritt å benytte. Derfor vil en instans av et scenario nødvendigvis ikke inneholde alle roller og informasjonspakker som er beskrevet. En instans av et scenario vil derfor vanligvis være et subsett av det scenariet som ble beskrevet i operativt virksomhetsperspektiv.

Det er nødvendig å vurdere alternative angrepsmåter som støtter subsett av scenarier. Et alternativ er å lage omfattende scenarier i operativt virksomhetsperspektiv, med en fravalgs tankegang. Med fravalgstankegang mener jeg at en har en stor funksjonalitetsmengde med tanke på roller, informasjonspakker og scenarioattributter, og velger ut deler av denne mengden ved implementering. Dette tilsvarer i stor grad dagens tankegang ved bruk av EDIFACT. Som tidligere beskrevet har en sett en del problemer med denne tankegangen knyttet til inkompatible funksjonalitetsmengder og usymmetrisk koding og dekoding av meldingsinnhold.

Jeg foreslår å lage flere basis rollemodeller som har definerte grensesnitt overfor hverandre. Disse rollemodellene kan så settes sammen som byggeklosser til en sammensatt rollemodell. For å oppnå dette bruker jeg OOram syntese.

Et sett av basis rollemodeller skal kunne settes samme til en sammensatt rollemodell for å støtte utførelsen av en forretningstransaksjon. En av disse basis rollemodellene velges som den mest sentrale. Ut fra en tilvalgstankegang kan en integrere rollemodeller med hverandre til en støtter utførelse av en ønsket forretningstransaksjon. De mest sentrale rollemodellene må ikke kunne velges bort, fordi de vil være helt sentrale i alle instanser av et scenario.

Følgende begreper vil jeg bruke videre:

En forretningstransaksjon beskrives ved en eller flere rollemodeller
En rollemodell er en beskrivelse av hvordan informasjonsflyten i et scenario er

7.2.2 Roller

I kapittel seks beskrev jeg hvordan OOram bruker rollemodeller og tilstandsdiagrammer for roller. I det videre arbeidet vil jeg benytte meg av dette. Jeg vil i dette avsnittet presisere forholdet mellom rolle og EDI-aktør.

Skillet mellom begrepene rolle og EDI-aktør er viktig å fremheve fordi de representerer to forskjellige abstraksjonsnivåer. En rolle er en modell av ekstern adferd til en generisk virksomhet i et scenario. En EDI-aktør er en virksomhet som utøver, eller er tenkt å utøve, roller i et scenario når scenariet er instansiert. Sammensatte rollemodeller beskriver hvordan samspillet mellom EDI-aktører skal kunne være i en instans av et scenario.

I [DIS] sies det følgende om rollebegrepet "role: an entity which models an external intended behaviour (as allowed within a scenario) of an organisation". En av intensjonene med Åpen-edi referansemodellen er at den ikke skal stille krav om hvordan utførelsen av en rolle skal gjøres internt hos en EDI-aktør. Roller som er beskrevet i henhold til referansemodellen sier bare noe om hva som må utføres, og stiller krav til grensesnittene mellom rollene. Dette blir imidlertid et dilemma når flere roller utøves av samme EDI-aktør. Grensesnittet mellom rollene er da et internt anliggende hos den EDI-aktøren som utøver rollene. På denne måten legger også Åpen-edi referansemodellen premisser for hvordan utførelsen internt i en organisasjon skal foregå, og det bryter med intensjonen. Jeg foreslår at dette kan løses ved at en tillater proprietære grensesnitt mellom roller som utøves av samme EDI-aktør, men at standarden må følges for roller som kommuniserer med andre EDI-aktørers roller.

7.2.3 Informasjonspakker

I dette avsnittet vil jeg se på hvordan informasjonspakker kan realiseres i en objektorientert tankegang. Informasjonspakker er definert i [DIS] som en semantisk datamodell av de meldinger som utveksles mellom roller. I tillegg til utveksling av instanser av informasjonspakker, vil det mellom EDI-aktører utveksles meldinger knyttet til lavere lags protokoller i teknologisk tjenesteperspektiv. Disse meldingene diskuterer jeg ikke her, men de er en forutsetning for at informasjonspakker skal kunne utveksles. Informasjonspakker blir beskrevet ved basispakker og tilleggspakker. Beskrivelsen vil bli utført av brukergrupper.

Mottaker av en informasjonspakke må vite hva innholdet er før han aksepterer å ha mottatt den. I dagens EDI-løsninger benyttes vanligvis en eller flere av følgende kvitteringsnivåer:

kvittering mellom meldingshåndteringssystemene, eventuelt kvitteringsmekanismer i filoverføringsprotokoller
kvittering for godkjent syntaks i meldingen
kvittering for at innholdet er akseptert

Det vil si at all EDI-utveksling kan sammenliknes med rekommandert post. Du godtar og kvitterer for at du har tatt i mot en informasjonspakke, ofte før du har godkjent innholdet. For å effektivt kunne utøve forretningstransaksjoner ved hjelp av EDI, tror jeg at det vil være hensiktsmessig at antall avviste informasjonspakker, på grunn av ikke akseptert innhold, er lavt. Avsender av en informasjonspakke må ikke kunne diktere hva mottaker skal motta og forplikte seg i forhold til. Innenfor de rammene scenariobeskrivelsen setter er det mottaker som skal kunne sette grensene for hva han ønsker som gyldige informasjonspakker. Mottaker må ha mulighet til å sette begrensninger på hva slags forretningstransaksjoner han er villig til å delta i.

Mens EDIFACT benytter en fravalgsmodell fra en omfattende internasjonal meldingsstandard, foreslår jeg å snu oppbyggingen av informasjonspakker til å være basert på en spesialisering av objekter, dette kaller jeg en tilvalgsmodell. Problemer knyttet til fravalgstankegangen hos EDIFACT er diskutert i avsnitt 2.5. Hvordan denne tilvalgsmodellen er tenkt å fungere er forklart under. Tilvalgsmodellen er et tilleggsforslag til Åpen-edi referansemodellen.

For å kunne benytte en tilvalgsmodell har jeg valgt å beskrive at informasjonspakke består av to typer enheter, basispakker og tilleggspakker.

Alle som benytter informasjonspakken må forholde seg til basispakken, og den skal være tilstrekkelig for å kunne drive helt enkel informasjonsutveksling. I forhold til EDIFACT er dette en utvidelse siden det som er påkrevd å bruke i EDIFACT-meldingstyper er i hovedsak tjenestesegmenter og et fåtall segmenter med nyttedata (INVOIC 95.2 har kun tre segmenter med nyttedata som er påkrevde å bruke, "BGM", "DTM" " MOA").Videre vil jeg definere tilleggspakker til informasjonspakken som spesialiserer og utfyller basispakken, dette er skissert i Figur 22. Både basispakker og tilleggspakker må støttes fullt ut av EDI-aktørenes interne interorganisatoriske systemer. Med fullt ut mener jeg at en ikke kan velge å ikke støtte deler av en basis- eller tilleggspakke. Det vil derfor sannsynligvis være behov for å dele basis- og tilleggspakkene opp i små enheter. Hvis en tillater valgfrihet i deler av en tilleggspakke ved implementering får en problemer med inkompatible funksjonalitetsmengder knyttet til informasjonspakkene. Dette vil tilsvarer dagens problem med inkompatible funksjonalitetsmengder av EDIFACT-meldinger.

Jeg tror det vil bli behov for å kunne benytte proprietære informasjonspakker. Fordi det vil ta tid å få utviklet generiske informasjonspakker. Det kan også være tilfelle der enkelte aktører ønsker å ha lukkede markeder. Bruk av proprietære informasjonspakker vil kunne gi denne lukkingen. Bruk av proprietære informasjonspakker er knyttet til dilemmaet om valg av brukergruppe for de informasjonspakker som utvikles. Dilemmaet er diskutert i kapittel 2.7.

Hensikten med denne måten å bygge opp informasjonspakkene på er at alle skal benytte de samme byggeklossene (basis- og tilleggspakker). Ved implementering av et internt interorganisatorisk system hos en konkret EDI-aktør vil det være nødvendig å velge hvilke roller og tilhørende informasjonspakker EDI-aktøren ønsker å kunne utøve. Systemet blir deretter implementert på basis av disse valgene. Ved instansiering av et scenario forhandler EDI-aktørene om hvilke byggeklosser alle de involverte må støtter. Deretter utveksles instanser av informasjonspakkene. [Lehmann] har i sin artikkel skissert denne todelingen av EDI-utvekslingenen. Først forhandling av hvilken informasjon som skal utveksles, så utveksling av en instans av informasjonspakken. [Lehmann] henter sitt løsningsforslag fra området kunstig intelligens, hvor han viser et eksempel på forhandlingsdialog mellom EDI-systemer.

En viktig forutsetning her er at jeg ikke har som utgangspunkt at alle informasjonspakker skal være like. Konseptet med tilleggspakker tillater i en del tilfeller enklere versjonshåndtering, fordi en ny versjon av en tilleggspakke kan realiseres ved at den gamle tilleggspakken blir spesialisert. På denne måten vil de interne interorganisatoriske systemene hos den enkelte EDI-aktør lettere kunne være kompatible med eldre versjoner av informasjonspakker. Utviklingen av Åpen-edi referansemodellen har som intensjon at det ikke skal være nødvendig med proprietære informasjonspakker. Jeg har her skissert løsningen med tilvalgstankegang som tilfredsstiller Åpen-edi referansemodellen, og som i tillegg kan håndtere bruk av proprietære tilleggspakker. Jeg mener at dette løsningsforslaget ikke bryter med intensjonen til Åpen-edi referansemodellen, men tillater å gå ut over denne intensjonen.

All nødvendig informasjon om basispakken og de relevante tilleggspakkene vil ligge tilgjengelig i operativt virksomhetsperspektiv repository. Dette gjør at nødvendig informasjon om informasjonspakkene er tilgjengelig under generering av de interne interorganisatoriske systemene, og mens scenariet er aktivt. Eventuelle proprietære tilleggspakker må behandles spesielt.

En informasjonspakke består av følgende:

Klasse informasjonspakke

boolean procedure sjekkSykel(pakke);
attributter
peker basispakke

Klasse pakke

attributter
peker pakke(1:n)

Pakke Subklasse basispakke

attributter

Pakke Subklasse tilleggspakke

attributter

Figur 22
Linjene i Figur 22 angir pekerstruktur.

Prosedyren sjekkSykel(pakke) sjekker at det ikke er sykler i grafen. Det vil kunne forekomme at to eller flere tilleggspakker ytterligere kan spesialiseres med samme tilleggspakke. Grafen vil da bli en rettet graf og ikke et tre. Med mindre det lages restriksjoner mot sykler vil sykler kunne forekomme i en rettet graf. Sykler oppfatter jeg som såpass kompliserende at jeg ikke ønsker å tillate det. Hvis sykler skulle tillates ville det skape problemer med å bestemme hvilke tilleggspakker som blir spesialisert av hvilke, siden alle tilleggspakker i samme sykel kan tolkes til å spesialisere hverandre.

Eksempel på bruk av informasjonspakke med spesialisering: Ta utgangspunkt i en enkel transportinstruksjon (data som beskriver avsender, mottaker av et vareparti, samt antall kolli og vekt på det som skal transporteres). Man definerer en basispakke for transportinstruksjon som er så enkel at alle som skal bruke den oppfatter det som står i basispakken som relevant. Til denne basispakken knytter man for eksempel to tilleggspakker. En tilleggspakke for eksportrettet transport, og en tilleggspakke for eksport av fisk til EU. Disse tilleggspakkene refererer til basispakken som kilde og summen av de tre, en basispakke og to tilleggspakker, vil kunne ses på som en fullverdig modell av hele informasjonpakken. Ved behov for flere nesten like tilleggspakker vil det være naturlig å lage en tilleggspakke med et sett av tilleggspakker som spesialiserer de forskjellige variantene.

Informasjonspakker har følgende egenskaper:

En informasjonspakke består av en basispakke, og null til mange tilleggspakker
En basispakke benyttes fullt ut. En kan ikke lage subsett
En tilleggspakke benyttes fullt ut. En kan ikke lage subsett
En basispakke kan ha null til mange tilleggspakker for spesialisering knyttet til seg
En tilleggspakke kan ha null til mange tilleggspakker for spesialisering knyttet til seg
Den rettede grafen skal være sykelfri

Attributtene i basispakker og tilleggspakker består av følgende ( I punktene som følger benyttes følgende syntaks: "/" betyr at en kan velge operand, "+" betyr at begge operandene må tas med) :

attributt = sammensatte semantiske enheter / atomære semantiske enheter
sammensatte semantiske enheter = sammensatte semantiske enheter + atomære semantiske enheter / atomære semantiske enheter

De to typer semantiske enheter er hentet fra [DIS]. Denne beskrivelsen tillater blant annet rekursjon, men den sier ikke noe om hvordan en skal kunne håndtere relasjoner (for eksempel 1-1, 1-N, N-1 og M-N) mellom semantiske enheter. Ved bruk datamodelleringsmetoder for relasjonsdatabaser vil en kunne representere relasjoner enkelt og en får et klart skille mellom modell og datarepresentasjon.

Fordelene ved å benytte en objektorientert tilvalgsmodell for å lage informasjonspakker er:

En informasjonspakke har utgangspunkt i samme basispakke uansett hvor mange tilleggspakker som benyttes. Dette gjør at en alltid kan forhandle seg frem til et sett av basis- og tilleggspakker som alle aktører støtter
En har gjenbruk av tilleggspakker mot forskjellige basispakker
En slipper problemer med subsett-tolking av informasjonspakker fordi enten hele eller ingenting av en basis- eller tilleggspakke skal benyttes

Fordelen med en slik objektorientert tilvalgsmodell er at en i hver instans av et scenario kan operere med meldingsutveksling med forskjellig funksjonsmengdekompleksitet. Meldingens funksjonsmengdekompleksitet forhandles frem, og en benytter det kompleksitetsnivå som EDI-aktørene ønsker. Funksjonsmengdekompleksiteten må støttes av alle involverte EDI-aktører. Mye av forhandlingen om tilleggspakker kan foregå ved initiering av scenariet, men siden et scenario skal kunne endres mens det utføres, må en kunne ha mulighet for å støtte forhandling om å legge til eller fjerne tilleggspakker under utførelsen av scenariet.

Hvis felles funksjonsmengde av en informasjonspakke mellom to EDI-aktører er for liten til at en kan gjennomføre ønsket scenario, har en feilet i valg av rolleutøvere. Ved instansiering av et scenario vil en velge rolleutøvere som støtter nødvendige informasjonspakker og tilleggspakker. (Denne problemstillingen belyses ytterligere i dette kapittel 7.4.)

7.2.4 Scenarioattributter

Det er behov for å beskrive mer i et scenario enn det beskrivelser av roller og informasjonspakker dekker. Denne tilleggsbeskrivelsen blir foretatt ved hjelp av det Åpen-edi referansemodellen kaller scenarioattributter. Scenarioattributter kan blant annet beskrive følgende:

juridiske forhold som må ivaretas
relasjoner mellom roller
relasjoner mellom informasjonspakker
krav til teknologiske tjenester som for eksempel sikkerhetsmekanismer m.m.

De punktene som er listet over er av vesentlig forskjellig karakter. Jeg tror derfor ikke det er hensiktsmessig å bruke en formell beskrivelsesteknikk for å dekke de forskjellige punktene. Jeg tror de juridiske sidene av et interorganisatorisk system bør modelleres med teknikker fra fagområdet. Dette fagområdet ligger utenfor denne oppgavens fagområde, og jeg vil derfor ikke komme inn på eksempler på modellering. I kapittel to "EDI, status og problemområder" avsnitt "Avtaler ved bruk av EDI" tar jeg opp hvordan det juridiske forholdet mellom EDI-aktørene nedtegnes i avtaleform. Ved bruk av Åpen-edi referansemodellen nedtegnes det avtaler for scenariene, og i det en melder seg som rolleutøver i et scenario har en samtidig akseptert gjeldende lover og regler i dette scenariet. En ønsker på denne måten å lage et veldefinert juridisk konsept for den elektroniske informasjonsutvekslingen.

Når det gjelder relasjoner mellom roller og mellom informasjonspakker finnes det metoder innen systemutvikling som fokuserer på relasjoner. En kan her se for seg metamodeller som er beskrevet i ER eller andre relasjonsnotasjoner.

7.2.5 Beskrivelse av teknologiske tjenester

På dette området er [DIS] kommet kort, og i henhold til de avgrensninger jeg har tatt om å holde fokus på operativt virksomhetsperspektiv kommer jeg ikke til å gå inn på hvordan teknologiske tjenester skal beskrives. I følge [DIS] skal de teknologiske tjenestene beskrives ved hjelp av formelle beskrivelsesteknikker.

7.2.6 Diskusjon for analyse og design fasen

Et scenario beskrives ved begrepene rolle, informasjonspakke og scenarioattributter. Når et internt interorganisatorisk system er i bruk vil det eksterne grensesnittet mot andre EDI-aktørers interne interorganisatoriske systemer være knyttet til ekstern adferd til de rollene en selv utøver. Det vil si at det system som utøver en rolle overfor andre EDI-aktører har ansvar for at scenarioattributter, forretningslogikk knyttet til informasjonspakker og bruk av teknologiske tjenester m.m. er i overensstemmelse med scenariobeskrivelsen. For implementasjonen av det enkelte interne interorganisatoriske system ville det være mer hensiktsmessig å ha en beskrivelse av roller hvor scenarioattributter, forretningslogikk knyttet til informasjonspakker og bruk av teknologiske tjenester m.m. var underlagt den enkelte rollen. Dette ville være i samsvar med at det er den eksterne adferd hos rollene som skal beskrives.

På bakgrunn av dette er det mulig en i det videre arbeidet med Åpen-edi referansemodellen bør se på alternativer til å ha scenarioattributter og informasjonspakker som egne begrep på lik linje med roller. Eventuelt kan en skissere hvordan implementasjonen av roller skal inkludere scenarioattributtene og den forretningslogikk som tilhører forskjellige informasjonspakker. En tett knytting av informasjonspakker og den tilhørende forretningslogikk ville være hensiktsmessig. Dette vil også være en naturlig konsekvens av et objektorientert fokus på informasjonspakker.

Tollpost-Globe

Hvis Tollpost-Globe skulle benyttet den metodikk jeg beskriver i dette avsnittet ville de kommet frem til andre løsninger enn det de har i dag. Hovedforskjellen ville vært at de proprietære løsninger som benyttes i dag ikke ville blitt registrert i operativt virksomhetsperspektiv-repository. Den proprietær løsningen gir tett kundebinding, spesielt gjelder dette for små og mellomstore bedrifter. Denne tette kundebindingen ville forsvunnet fordi kundene ikke lenger vil være avhengig av Tollpost-Globes implementasjonsguider og formater. Tollpost-Globe ville ikke på samme måte være premissgiver for hva av informasjons som skulle utveksles og hvordan. De kunne vært med i den brukergruppen som skulle beskrive transportscenariet, men de ville ikke hatt noen vetorett.

7.2.7 Oppsummering for analyse og design fasen

Jeg har i denne fasen beskrevet hvordan et scenario beskrives ved roller, informasjonspakker og scenarioattributter. Jeg har lagt stor vekt på beskrivelsen av informasjonspakker fordi utvekslingen av informasjon er et hovedpoeng med et interorganisatorisk system, og fordi tilvalgsmodellen er et tillegg til Åpen-edi referansemodellen.

Det er viktig å poengtere at analyse og design vanligvis ikke utføres av en enkelt EDI-aktør, men av brukergrupper som skal lage generiske scenario beskrivelser.

7.3 Implementering av interorganisatoriske systemer

Denne fasen skal ta for seg selve implementeringen av et internt interorganisatorisk system som baserer seg på Åpen-edi referansemodellen. Resultatene fra forrige fase var formelle beskrivelser av scenarier, og formelle beskrivelser av teknologiske tjenester. Det interne interorganisatoriske systemet blir implementert på basis av resultatene fra forrige fase. I denne fasen er den enkelte EDI-aktør i fokus. Det interne interorganisatoriske systemet som den enkelte EDI-aktør skal benytte blir nå satt sammen ut fra godkjente scenariobeskrivelser. For å kunne foreta riktige valg av hvilke roller en EDI-aktør skal kunne utøve, og hvordan disse rollene skal kunne utøves, vil det være viktig at EDI-aktøren har god forståelse for konsekvensene av sine valg.

[DIS] sier at en skal legge de formelle scenariobeskrivelsene i et repository. Videre skal disse formelle beskrivelsene ved hjelp av CASE verktøy, og i kraft av at de er formelle beskrivelser, kunne resultere i systemer som kan utøve roller. Systemene skal også kunne interpretere scenariobeskrivelsene på en slik måte at de utøver roller. Dette er en konsekvens av definisjonen av Åpen-edi formell beskrivelsesteknikk. Noe forenklet kan en si at scenariobeskrivelsene skal automatisk, ved hjelp av en CASE type verktøy, kunne bli til et internt interorganisatorisk system. I forbindelse med beskrivelsen rundt hvordan automatisk generering av interorganisatorisk system foregår foretar jeg en del forenklinger, og går ikke i dybden på alle problemstillinger. Jeg vil i det videre gå ut fra at denne genereringen er mulig å få til, mer eller mindre automatisk, av en Åpen-edi systemgenerator. Jeg vil heller ikke gå inn på grensesnitt internt i det interne interorganisatoriske systemet.

Jeg velger å se på utviklingen av de teknologiske tjenestene som en oppgave for programvareleverandører. Grunnen til dette er at det spesielt for små og mellomstore bedrifter vil være for omfattende for den enkelte virksomhet å selv utvikle denne delen av EDI-løsningen. Dette fører til at programvareleverandører utvikler de teknologiske tjenestene som skal danne grunnmuren i de interne interorganisatoriske løsningene. Den enkelte EDI-aktør tar for seg de rollemodeller som er relevante for virksomheten, og velger de rollene fra forskjellige rollemodeller som han ønsker å kunne utøve. Disse rollene blir satt sammen til en sammensatt rolle ved hjelp av OOram syntese. Tilstandsdiagrammene for de forskjellige rollene blir satt sammen, og det blir automatisk generert et internt interorganisatorisk system på bakgrunn av rollemodeller og tilstandsdiagrammer.

Fasen består av tre sentrale oppgaver. Disse tre punktene er presiseringer og tillegg til [DIS].

Programvareleverandører utvikler programvaren som er i henhold til de formelle beskrivelsene gitt i teknologisk tjenesteperspektiv repository, og lager et programvarebibliotek som kan benyttes av en Åpen-edi systemgenerator. -- Jeg tror spesielt små og mellomstore bedrifter vil benytte seg av å kjøpe nødvendig programvare fra eksterne leverandører. Dette bl.a. fordi utviklingen av denne type systemer er kompleks.
En EDI-aktør tar tak i scenariobeskrivelser fra forrige fase, og setter sammen en ønsket sammensatt rolle. Han velger hvilke informasjonspakker og funksjonalitetsmengden til informasjonspakkene han ønsker å kunne utveksle. Videre må han velge hvordan valgfrie scenarioattributter skal håndteres. Hvis deler av en rolleutøvelse skal delegeres må det komme frem på dette tidspunkt. Disse valgene til sammen dekker den nødvendige funksjonalitet som kreves for å være aktør i ønsket forretningstransaksjon. Det er viktig å merke seg at disse valgene legger grunnlaget for hvilke varianter av scenario instanser EDI-aktøren vil kunne delta i.-- For EDI-aktøren er det egentlig her selve utviklingen av det interne interorganisatoriske systemet foregår, fordi det er her han kommer med de valg som påvirker egen løsning. Valgene som kan foretas er innenfor scenariobeskrivelsene og dette fører til at EDI-aktøren vil ha begrenset mulighet for påvirkning. Fordelen er at han slipper å selv analysere og designe de aktuelle rollene i forskjellige scenarier som er av interesse. Han slipper også å tenke på om samspillet med andre rolleutøvere er ivaretatt. Dette samspillet skal være ivaretatt av den brukergruppen som har beskrevet scenariet. Sammensetting av tilstandsoversikter gjøres i forbindelse med implementering av det interne interorganisatoriske systemet.
EDI-aktøren må skaffe seg tilgang til nødvendige produkter og programbibliotek, og må velge en eller flere programvareleverandører. En Åpen-edi systemgenerator levert av en programvareleverandør genererer et internt interorganisatorisk system på basis av leverandørens programvarebibliotek og EDI-aktørens valg fra punktet over.

Figur 23
Forklaring til notasjon i Figur 23: Databasemetaforer viser hvor produkter og resultater er lagret. Sirklene angir hvem som utfører aktiviteter.

En EDI-aktør skal kunne delegere hele eller deler av en rolle til en annen part som oppfyller rollen på vegne av EDI-aktøren. Denne funksjonalitetsoppdelingen må gjenspeiles i de konkrete interne interorganisatoriske systemene.

Når det interne interorganisatoriske systemet er generert må det installeres og testes. EDI-aktøren må videre velge leverandør av telekommunikasjonstjenester, og teste at disse tjenestene virker. Eventuelt må han også koble seg opp mot en tjenesteleverandør av verdiøkende tjenester avhengig av om scenariet han skal delta i krever det, eller om EDI-aktøren har valgt å delegere deler av rolleutøvelsen til tredjepart.

7.3.1 Diskusjon

Jeg tror det svakeste punktet i denne fasen er at en i [DIS] forutsetter at det skal gå an å foreta en mer eller mindre automatisk generering av et internt interorganisatorisk system. Problemområder som skreddersøm av grensesnitt, spesielt mellom EDI-løsningen og interne datasystemer, vil være vanskelig å løse ved bruk av automatikk i genereringen. Hvis denne integreringen skulle la seg realisere ville allikevel manuelle rutiner gjøre at det må foretas skreddersøm. Videre vil kontekstavhengig bruk og presentasjon av data kunne bli problematisk.

Videre vil jeg påpeke problemet med at alle må velge hvilken funksjonalitet de skal kunne utøve ut fra ett sett med predefinerte scenarier. Dette vil kunne føre til at de involverte virksomhetene må standardisere sin måte å utføre forretningsvirksomheten på, dette er i samsvar med konklusjonen til [Hørlück93] og det er ikke i overensstemmelse med intensjonen til Åpen-edi referansemodellen.

Tollpost-Globe

Tollpost-Globe har kjøpt noen programpakker og integrert disse med egenutviklede systemer. Ved å kjøpe et internt interorganisatorisk system som baserer seg på standard scenarier trenger en ikke egen utviklingsavdeling. En mulig ulempe vil være at en har mindre anledning for skreddersøm, og en vil være avhengig av andre for å videreutvikle virksomhetskritiske systemer. Spesielt skreddersøm mot interne datasystemer og rutiner vil være problematisk. Denne bindingen mot andre leverandører kan være både gunstig og ugunstig avhengig av strategisk synspunkt. Det er verd å merke seg at det er mulig å outsource utviklingsaktiviteter.

7.3.2 Oppsummering for implementering av interorganisatoriske systemer

Ved starten av denne fasen forelå det scenariobeskrivelser og beskrivelser av teknologiske tjenester. Ut av denne fasen kommer et implementert internt interorganisatorisk system som skal kunne samspille med andre EDI-aktører sine interne interorganisatoriske systemer. Det interne interorganisatoriske systemet skal etter denne fasen være klart til bruk.

7.4 Det interorganisatoriske systemet tas i bruk

Forutsetningen for at et scenario skal kunne instansieres er at det finnes EDI-aktører som har implementert interne interorganisatoriske systemer basert på Åpen-edi referansemodellen. EDI-aktører må være registrert i rolle repository som utøvere av rollene som inngår i det aktuelle scenariet. Det første en EDI-aktør bør gjøre er å melde seg som rolleutøver i rolle repository, med hvilke roller og hvilke informasjonspakker med tilleggspakker han støtter utøvelsen av. Rolle repository er tilgjengelig via teknologiske tjenester. Noen rolleutøvere vil i kraft av den rollen de ønsker å utøve kunne instansiere et scenario. Først må den rolleutøveren som skal instansiere scenariet få tak i de andre rolleutøverne i scenariet. Denne søkingen etter rolleutøvere vil sannsynligvis være nyttig å legge i et eget scenario, kalt pre-scenario, som overfører resultatet av søkingen til den EDI-aktøren som initierer scenariet. Når kandidater til utøverne er funnet starter forhandlingene som avgjør hvem som får tilslag til å utøve de forskjellige rollene. I denne pre-scenario fasen kan en gjerne se for seg en form for børsing av rolleutøvere, hvor en forhandler om rabatter og andre leveringsbetingelser. For å komme videre mot et instansiert scenario må følgende betingelser være oppfylt:

Alle påkrevde roller i den sammensatte rollemodellen må være besatt. En må velge hvilke valgfrie roller som skal besettes, og besette dem.
Nødvendige informasjonspakker, og ønskelige tilleggspakker, må støttes av de aktuelle rolleutøverne
Hvilke tilstander som er valgfrie og betinget for de forskjellige rollene må avklares
EDI-aktørene må forhandle seg frem til enighet om scenarioattributter. For eksempel bruk av teknologisk tjenester der dette er valgfritt eller betinget.

Når dette er klart kan den rolleutøver som i henhold til sitt tilstandsdiagram skal kunne initialisere scenariet sende sin første informasjonspakke, og scenariet er aktivt.

Det er viktig å merke seg at EDI-aktørene kan delegere funksjonalitet og ansvar til andre aktører. Denne oppdelingen gjør informasjonsflyt og ansvarsforhold mer kompleks. Dette er vist med to eksempler under.

Eksempel I : En EDI-aktør A setter bort utsendelse og innkreving av fakturaer til en tredjepart B. Da må de EDI-aktører som mottar fakturaer fra B vite at B handler på oppdrag fra A, og at B har overtatt forpliktelser og rettigheter som A opprinnelig hadde. Informasjonsflyten og ansvarsforhold blir mer kompleks for de EDI-aktørene A handler med.
Eksempel II (Bruker samme A og B som over): Hvis denne oppdelingen skulle vært usynlig for de EDI-aktørene som handler med A måtte de teknologiske tjenestene kunne kapsle inn rolleoppdelingen mellom A og B. I så fall ville informasjonsflyten mellom A og B bli kompleks siden de to til sammen kun skal ha en ekstern adferd. En løsning ville vært at alle informasjonspakker til og fra B alltid gikk via A. Da ville A bare delvis ha delegert rollen, fordi EDI-aktørene A handler med ville benytte seg av teknologiske tjenester knyttet til As interne interorganisatoriske system.

Noen aktører, som ikke er beskrevet som selvstendige roller, vil være aktive i forbindelse med utførelsen av et scenario. Et eksempel kan være en aktør som tilbyr "Åpen-edi globale repositorytjeneste". Denne globale repository tjenesten er en presisering og utvidelse av det som står i [DIS]. Tjenesten skal blant annet dekke følgende behov:

Søking etter rolleutøver i rollerepository
Behov for tilgang til all formell scenariobeskrivelse til eget scenario mens en er aktiv. Behovet avhenger av hvordan Åpen-edi systemet er implementert.

Juridiske forhold er i hovedsak knyttet til scenarioattributter. Når et scenario er aktivt er ansvaret for å håndtere juridiske problemer lagt til rollene som den enkelte EDI-aktør utøver.

7.4.1 Forhandlinger

Rammene for denne forhandlingen er scenariobeskrivelsene. Forhandlingssituasjonen mellom to EDI-aktører baserer seg på enten å finne en løsning som begge støtter, eller at begge støtter flere løsninger og en ønsker å finne den løsningen som er mest hensiktsmessig.

Siden det interne interorganisatoriske systemet hos den enkelte EDI-aktør er individuelt tilpasset vil det si at de ikke håndterer samme funksjonalitetsmengde og de benytter ikke nødvendigvis de samme teknologiske tjenestene. Mottaker av informasjonspakker må i forbindelse med forhandlingen av hva som skal kunne sendes kunne avvise bruk av tilleggspakker han selv ikke støtter. Hvis en EDI-aktør avviser bruk av en tilleggspakker, vil de andre EDI-aktørene ha full rett til å fjerne den aktuelle EDI-aktør fra deltakelse i scenariet, fordi han ikke oppfyller det ønskede krav til rollen han skal utøver. Forhandlingene vil gjelde roller, informasjonspakker og scenarioattributter. Disse forhandlingene vil skje før initialisering av et scenario, eller mens et scenario er aktivt.

En av fordelene ved objektorientert modellering av scenarier er den styrken det ligger i å kunne forhandle seg frem til hvilken grad av spesialisering en ønsker. Beskrivelse av hvordan spesialisering er tenkt er spesielt tatt opp i tilknytting til informasjonspakker, men vil også gjelde for roller og scenarioattributter. I et omfattende scenario vil det ikke være realistisk å tro at en kan forhandle seg frem til et fullstendig scenario forløp ved initiering. Roller vil bli initiert og terminert på basis av tilstander midt i scenariet, og det kan oppstå uforutsette komplikasjoner som gjør at en må terminere scenariet før intensjonen er fullført. For eksempel vil det være meningsløst å fullføre et scenario for transport hvis varen som skal transporteres er blitt ødelagt eller at den ikke lenger eksisterer. Her vil det være behov for at et eller flere scenarier som beskriver avvikshåndtering av forskjellig slag er inkludert i det sammensatte scenariet.

Når forhandlingen er ferdig vil den enkelte EDI-aktør ha forpliktet seg i forhold til hva andre forventer av ham, og hva han kan forvente av andre. Åpen-edi referansemodellen tillater på denne måten å ha dynamiske implementasjonsguider. Det vil si at i forhold til bruk av for eksempel EDIFACT, vil en her delvis forhandle seg frem til den meldingshåndbok og de implementasjonsguider som skal gjelde.

7.4.2 Pre- og postscenario

Det vil være behov for et pre-scenario hvor en foretar de nødvendige forhandlinger tilknyttet et scenario. Dette prescenariet vil det muligens være hensiktsmessig å aktivisere som en egen scenario i forkant av det scenariet som skal dekke ønsket forretningstransaksjon. Videre vil det være behov for et postscenario som tar seg av eventuell uforutsett terminering og sørger for at alle EDI-aktører og instanser av andre enheter som er involvert blir terminert.

7.4.3 Diskusjon, det interorganisatoriske systemet tas i bruk

Bruk av rolle repository gjør at de forskjellige EDI-aktørene er synlig for hverandre. EDI-aktørene benytter samme scenariobeskrivelse som utgangspunkt for utvikling av interne interorganisatoriske systemer. De benytter samme teknologiske tjenester, og informasjon om hvilke EDI-aktører som utøver hvilke roller er tilgjengelig. Så lenge EDI-aktørene har felles mål og interesser nærmer en seg med dette et godt og åpent interorganisatorisk system.

Prisen for å oppnå denne interoperabiliteten både teknologisk og forretningsmessig er at alle må forholde seg til de rammene som er satt; det vil si begrensninger og forpliktelser forbundet med scenariobeskrivelsene. Videre vil det kun være mulig å benytte en definert plattform av teknologiske tjenester. Utvikling og videreutvikling av teknologisk og forretningsmessig interoperabilitet styres av andre enn en selv.

Forhandlingssituasjonen mellom to EDI-aktører baserer seg på enten å finne en løsning som begge støtter, eller at begge støtter flere løsninger og en ønsker å finne den løsningen som er mest hensiktsmessig. Hvert element en forhandler om, skal kunne påvirke de interne datasystemer, rutiner og manuelle operasjoner som er knyttet til de interne interorganisatoriske systemene. Forhandling om de elementer som er knyttet til teknologiske tjenester betyr at alternativene det forhandles om må være implementert hos EDI-aktørene som forhandler. Hvis en har implementert et interorganisatorisk system som kan utøve bare det som er påkrevd, vil en ha en enkel forhandlingssituasjon, men en vil samtidig kunne risikere å være en lite interessant handelspartner. Dette fordi en kanskje ikke støtter tilleggspakker eller valgfrie teknologiske tjenester som de andre EDI-aktørene ønsker å benyttes seg av.

Tollpost-Globe

Å benyttet en egen formidlingssentral, hvor Tollpost-Globe selv definerer lovlige EDI-aktører, ville stride mot hensikten til rolle repository og åpenheten.

7.4.4 Oppsummering, det interorganisatoriske systemet tas i bruk

Ved start av denne fasen var det interne interorganisatoriske systemet implementert, men ikke tatt i bruk. Dette avsnittet har beskrevet hvordan en EDI-aktør melder seg som rolleutøver i et scenario, hvordan et scenario blir instansiert og hva som må være oppfylt for å kunne si at et scenario er instansiert. Videre er et eksempel på en aktør som tilbyr "Åpen-edi globale repositorytjeneste» vist. Dette er en aktør som ikke er modellert som en egen rolle, men som allikevel er en del av et instansiert scenario.

Forhandling av roller, informasjonspakker og scenarioattributter er beskrevet. Disse forhandlingene vil skje før initialisering av et scenario, eller mens et scenario er aktivt. Konsekvenser av forhandlinger er tatt opp til diskusjon.

Pre- og postscenario er forklart og et eget scenario for forhandling er skissert som et mulig pre-scenario.

7.5 Oppsummering for bruk av Åpen-edi referansemodellen og OOram ved utvikling av interorganisatoriske systemer

Jeg har i dette kapitlet vist hvordan en kan benytte Åpen-edi referansemodellen som rammeverk, og OOram som formell beskrivelsesteknikk for å foreta analyse og design, implementering og bruk av interorganisatoriske systemer. For hver enkelt fase har jeg diskutert konsekvenser generelt, og spesielt i forhold til Tollpost-Globe. Hvem som utfører de forskjellige oppgavene i de enkelte fasene er beskrevet.

OOram er i utgangspunktet ikke laget for å se på sammenhengen mellom interne interorganisatoriske systemer, men metoden fokuserer på roller i et objektorientert perspektiv. Dette fokus tilsvarer nettopp sammenhengen mellom interne interorganisatoriske systemer som baserer seg på rollemodeller.

Grensesnittet mellom rollene er sentrale ved bruk. Når et scenario skal initialiseres og roller skal utøves må scenarioattributtene og den forretningslogikk som er knyttet til bestemte informasjonspakker være integrert i rollene. En bør derfor vurdere om et scenario blir hensiktsmessig beskrevet ved å bruke roller, informasjonspakker og scenarioattributter som likestilte begreper. Den implementerte rollen har ansvar for håndtering av scenarioattributtene og forretningslogikken som er knyttet til bestemte informasjonspakker.

Faseinndelingen som er skissert, med omfattende faser hvor for eksempel analyse og design er i samme fase, er hensiktsmessig for mitt formål. Jeg skal kun lage en overordnet beskrivelse som skisserer hvordan Åpen-edi referansemodellen og OOram sammen kan brukes som systemutviklingsmetode. Jeg tar ikke stilling til hvordan iterasjoner i analyse og design skal gjennomføres. Jeg har drøftet hvordan versjonshåndtering kan foregå. Nye versjoner av de interne interorganisatoriske systemene vil være generert på bakgrunn av iterasjoner i fasene. Metoden som er skissert kan derfor karakteriseres som en enkel fossefallsmetode, med mulighet for iterasjoner som resulterer i nye versjoner av både scenariobeskrivelsene og de interorganisatoriske systemene som bygger på disse scenariobeskrivelsene.

Utviklingen av scenarier som følger Åpen-edi referansemodellen vil komme til å foregå relativt langt fra dem som er potensielle brukerne. Dette kan føre til at brukernes behov ikke blir tilstrekkelig tatt hensyn til, og kan sammenliknes med noe av den kritikken som utviklingen av EDIFACT-standarden er blitt utsatt for.

Alle EDI-aktører må velge hvilken funksjonalitet de skal kunne utøve, ut fra ett sett med predefinerte scenarier. Dette kan føre til at EDI-aktører må standardisere sin interne måte å utføre forretningsvirksomheten sin på, og det er ikke i overensstemmelse med intensjonen til Åpen-edi referansemodellen.

Når en EDI-aktør melder seg som rolleutøver i et scenario har han samtidig akseptert lover og regler tilknyttet dette scenariet. En ønsker på denne måten å lage et veldefinert juridisk konsept for den elektroniske informasjonsutvekslingen.

Tilbake til innholdsfortegnelsen