5 Åpen-edi referansemodellen

I dette kapittelet beskriver jeg hva Åpen-edi referansemodellen er og som kilde bruker jeg [DIS]. Jeg har valgt ikke å trekke inn faktorer for utbredelse og problemer med bruk av dagens EDI. Fordi jeg først vil beskrive Åpen-edi referansemodellen slik den er definert i [DIS]. I kapittel ni vurdere Åpen-edi referansemodell.

Videre i dette kapitlet vil jeg beskrive hvordan Åpen-edi referansemodellen blir utviklet, og hvordan referansemodellen er tenkt brukt. Begrepsapparatet jeg bruker for å beskrive Åpen-edi referansemodellen er i hovedsak hentet fra mine definisjoner, se kapittel en, avsnitt «Begrepsavklaringer». Disse definisjonene baserer seg i hovedsak på oversettelser og presiseringer av definisjonene i [DIS].

Åpen-edi referansemodellen utvikles av en komité i International Standards Organisation (ISO) som kalles JTC1 ISO/IEC SC30 Open-edi. Komitéen er sammensatt av deltakere fra mange land, deriblant fra Norge. De enkelte deltakerland har vanligvis nasjonale referansegrupper som kommer med forslag til endringer og tillegg til referansemodellen. Forslagene tas opp til diskusjon på møter i komitéen og beslutning om integrering eller avvisning av forslagene baserer seg på resultater av diskusjon eller avstemming.

Begrepene Åpen-edi referansemodell og Åpen-edi standarder vil jeg presisere på følgende måte:

Åpen-edi referansemodellen er et rammeverk for identifikasjon, utvikling og koordinering av Åpen-edi standarder. De krav som stilles i referansemodellen skal sikre interoperabilitet både virksomhetsmessig og teknologisk, mellom Åpen-edi standarder og mellom interne interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen [DIS, s.3].
Åpen-edi standarder er enkeltstandarder som er i overensstemmelse med Åpen-edi referansemodellen. For eksempel formelle beskrivelsesteknikker for operativt virksomhetsperspektiv, eller standarder som benyttes til å beskrive og /eller utvikle teknologisk tjenester. [DIS, s.2]

5.1 Hensikten med Åpen-edi referansemodell

Flere og flere varianter av interorganisatoriske systemer er tatt i bruk. Kostnaden med å etablere og ta i bruk interorganisatoriske systemer er høy. Lang tidshorisont, stort meldingsvolum og et begrenset antall involverte virksomheter har vist seg å gi interorganisatoriske systemer suksess.

De av målsetninger for Åpen-edi referansemodellen som jeg oppfatter som de viktigste er (i) det skal hurtig og kostnadseffektivt la seg gjøre å ta i bruk interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen, (ii) Åpen-edi referansemodellen skal føre til stor utbredelse av interorganisatoriske systemer, (iii) Åpen-edi referansemodellen skal sikre at interne interorganisatoriske systemer som baserer seg på internasjonale standarder skal kunne spille sammen både teknologisk og virksomhetsmessig. Punkt (i) er hentet fra innledningen i [DIS], punkt (ii) er en av intensjonene med å utvikle Åpen-edi referansemodellen og (iii) er hentet fra formålet med Åpen-edi referansemodellen.

Åpen-edi referansemodellen baserer seg på bruk av generiske internasjonale standarder. En skal dermed være i stand til å ta steget fra meldingsutveksling mellom kjente EDI-aktører som opererer innenfor et gitt avtaleverk, til informasjonsutveksling på tvers av bransjer og landegrenser. Predefinerte avtaler utover det som følger av at Åpen-edi referansemodellen benyttes skal ikke lenger være nødvendig. Åpen-edi referansemodellen introduserer standard scenarier og standard teknologiske tjenester til bruk i de interne interorganisatoriske systemene.

Referansemodellen er et rammeverk som andre standarder skal spille sammen i. Den setter krav til de standarder som benyttes ved design og implementering av interorganisatoriske systemer. En ønsker å unngå utvikling av overlappende eller inkompatible standarder til bruk ved EDI.

Ved å bruke referansemodellen forventer man at det blir lettere å etablere interorganisatoriske systemer, blant annet fordi man tar i bruk standard scenarier og benytter standard teknologiske tjenester som støtter utførelse av disse scenariene. Når et interorganisatorisk system basert på Åpen-edi referansemodellen tas i bruk, skal det ikke lenger være nødvendig med bilaterale avtaler mellom EDI-aktørene. Når en EDI-aktør melder seg på som rolleutøver i et scenario aksepterer han samtidig de lover og regler som er beskrevet i scenariet.

Åpenhet skal oppnås blant annet ved å gjøre scenarier og de tilhørende teknologiske tjenester tilgjengelig for alle som ønsker å delta. Åpenheten skal være middelet som gjøre det mulig å implementere Åpen-edi referansemodellen på tvers av virksomhetsområder.

Bruksområdet for Åpen-edi referansemodellen er design og implementasjon av interorganisatoriske systemer som støtter elektronisk utførelse av forretningstransaksjoner mellom virksomheter. Virksomhetene kan tilhøre forskjellige områder som privat, offentlig, industri m.m. Forretningstransaksjoner skal kunne involvere utveksling av flere typer data som tall, karakterer, bilder og lyd.

Åpen-edi referansemodellen skal fungere som koordinator og rammeverk for dem som utvikler Åpen-edi standarder. Nødvendige standarder som skal brukes til design og implementering av interorganisatoriske systemer basert på Åpen-edi referansemodellen skal bli identifisert, satt i sammenheng og utviklet i forhold til de retningslinjer referansemodellen setter. Referansemodellen legger ikke begrensninger og er uavhengig av følgende:

alternative implementeringer av interorganisatoriske systemer
forretningsinnhold og overenskomster
forretningsaktiviteter
virksomheter

Definisjon av Åpen-edi formell beskrivelsesteknikk i [DIS s. 4] er viktig og den er som følger:

«Open-edi Description Technique: a specifiction method such as a Formal Descripiton Technique, another methodology having the characteristics of a Formal Descriptions Tecnique, or a combination of such techiques as needed to formally specify BOV concepts, in a computer processible form.»

Forkortelsen BOV er det jeg kaller operativt virksomhets perspektiv, som blant annet omfatter scenariobeskrivelser.

Fra definisjonen er «in a computer processible form» sentralt. Dette betyr at scenariobeskrivelser beskrevet i en formell beskrivelsesteknikk skal kunne benyttes som kilde for et CASE verktøy til enten å lage, et system som kan utøve roller m.m. eller, et system som kan interpretere scenariobeskrivelsene slik at en kan utøve roller m.m.

5.2 Fokus for Åpen-edi referansemodellen

Åpen-edi referansemodellen fokuserer på forretningstransaksjoner fra to angrepsvinkler. Disse angrepsvinklene er operativt virksomhetsperspektiv og teknologisk tjenesteperspektiv.

Operativt virksomhetsperspektiv ser på følgende:

Semantikk i data som brukes i forretningstransaksjoner og tilhørende datautvekslinger
Regler for forretningstransaksjoner som operasjonelle overenskomster, avtaler og felles forpliktelser

Teknologisk tjenesteperspektiv ser på hvilke teknologiske tjenester som må til får å kunne utføre forretningstransaksjoner, det vil si:

hva tjenester skal inneholde
hvordan tjenestegrensesnittet er
hvilke protokoller som benyttes

5.3 Operativt virksomhetsperspektiv

Operativt virksomhetsperspektiv ser på hvordan det forretningsmessige samspillet mellom interne interorganisatoriske systemer skal beskrives og modelleres. Operativt virksomhetsperspektiv ser på alt som er relevant for å kunne ta riktige forretningsmessige beslutninger, og hva som må til for å kunne akseptere forpliktelser i forhold til andre EDI-aktører i et scenario. En vil skille mellom intern og ekstern oppførsel, hvor den eksterne oppførselen er av betydning for grensesnittet mot andre EDI-aktører.

Hvilke metoder som skal brukes for å beskrive og modellere forventet ekstern oppførsel vil være en del av det operativt virksomhetsperspektiv fokuserer på. Disse metodene kalles formelle beskrivelsesteknikker.

Med formell beskrivelsesteknikk menes: En spesifikasjonsmetode som bygger på et beskrivelsesspråk som benytter entydige regler for syntaks og semantikk [DIS]. Formelle beskrivelsesteknikker skal brukes til å beskrive scenarier. Åpen-edi referansemodellen har definert at scenarier skal beskrives ved hjelp av roller, informasjonspakker og scenarioattributter. Derfor må aktuelle formelle beskrivelsesteknikker kunne håndtere denne oppdelingen.

5.3.1 Scenario

Et scenario er en formell spesifikasjon av en klasse forretningstransaksjoner som har et felles forretningsmessig mål [DIS]. Forskjellige brukergrupper vil med utgangspunkt i Åpen-edi referansemodellen utvikle scenarier. Scenariene skal være mest mulig generelle og globale. Anbefalte og godkjente scenarier legges i et scenarioarkiv (repository). Det ønskelige er at scenarier er generiske, men det tilrettelegges for bruk av profiler ved instansiering av scenariene for å ivareta spesielle behov. Behovene kan for eksempel være av juridisk art relatert til land eller bransje.

En klassemodell av innholdet i et scenario kan skisseres på følgende måte:

Klasse Scenario

Karakteristika for scenario
Klasse Rolle
Karakteristika for rolle
Klasse Informasjonspakke
Karakteristika for informasjonspakke
Klasse Scenarioattributter
Karakteristika for scenarioattributter

Rolle
En rolle er en entitet som modellerer ekstern tilsiktet adferd (som er tillatt i henhold til Åpen-edi scenariet) av en EDI-aktør [DIS].

Informasjonspakke
En informasjonspakke er en semantisk beskrivelse av den informasjonen som utveksles mellom EDI-aktører i et scenario [DIS].

Scenarioattributter
Angir formell spesifikasjon av informasjon, relevant for scenariet som helhet. Informasjon som ikke er spesifikk til hverken roller eller informasjonspakker [DIS]. Eksempler på scenarioattributter er:

Relasjoner mellom roller
Hensikt med scenariet
Lover og regler som angår scenariet

5.4 Teknologisk tjenesteperspektiv

Teknologisk tjenesteperspektiv ser på det teknologiske samspillet mellom interne interorganisatoriske systemer. Det vil si de teknologiske tjenester som benyttes for å implementere et interorganisatorisk system og som gjør det mulig å utføre forretningstransaksjoner ved hjelp av interorganisatoriske systemer.

De teknologiske tjenestene skal gjøre det mulig å initiere og operere forretningstransaksjoner og spore fremdriften av forretningstransaksjoner. Eksempler på teknologisk tjeneste er følgende:

evne til å spore fremdriften i forretningstransaksjoner
forhandling av roller
interpretering av roller
administrering av kommunikasjon
mekanismer for oversettelse av informasjonspakker
sikkerhetsmekanismer
feilhåndtering og rapportering

Forhandling

Forhandlingene vil dreie seg om å bli enig om hvem som utøver hvilke roller, og på de områder hvor det er valgfrihet må en også bestemme hvordan disse rollene skal utøves. Videre vil en forhandle om informasjonspakker og innholdet i disse.

Basic Semantic Repository

Dette er en tjeneste som oversetter informasjonspakker mellom forskjellige formater. Definisjonen av informasjonspakke er: en semantisk formell beskrivelse av den informasjon som utveksles mellom interne interorganisatoriske systemer [DIS]. De problemene som diskuteres i avsnitt 4.9 «Kompatibilitet og kontekstavhengighet», vil være sentrale for denne tjenesten. Et eksempel: En EDI-aktør sender fra seg en EDI-melding basert på EDIFACT, og mottaker kan bare motta en X.12 type melding. Dette skal kunne gjøres ved hjelp av mappinger via et tredje generisk format som er definert i Basic Semantic Repository. Beskrivelse av Basic Semantic Repository er under utarbeidelse av en komité i International Standards Organisation (ISO). Dette er et stor og komplekst problemområde som jeg ikke kommer til å gå inn på i denne oppgaven. Jeg foreslår som videre arbeid en vurdering av Basic Semantic Repository.

Jeg har videreutviklet figuren som ble benyttet i kapittel to for å forklare hva EDI er. Jeg vil presisere at Figur 14 er en vesentlig forenkling av teknologisk tjenesteperspektiv, og den er ikke hentet fra [DIS]. Forenklet kan en dele teknologisk tjenesteperspektiv opp i tre hovedlag. Disse lagene er: automatisert rolleutøver, utvekslings- og sikkerhetstjenester og nett-tjenester.

Figur 14
Figur 14 viser to EDI-aktører som begge har implementert hvert sitt interne interorganisatoriske system. Til sammen utgjør de et eksempel på et interorganisatorisk system. Hvordan den enkelte EDI-aktør faktisk implementerer interne datasystemer i forhold til de datasystemer som er knyttet til teknologisk tjenesteperspektiv trenger ikke påvirke andre EDI-aktører. Interne datasystemer og teknologiske tjenester kan integreres i hverandre uten at det bryter med Åpen-edi referansemodellen.

Figur 14 viser ikke hvordan delegering av roller vil foregå, og den viser heller ikke samspillet med eventuelle tiltrodde tredjeparter eller tjenestetilbydere som ikke er modellert som rolleutøvere. Oppdelingen som er skissert i Figur 14 viser kun en av flere muligheter. Jeg går ikke i detalj inn på hvordan de enkelte elementene brukes eller ansvarsforholdene mellom dem, men vil i stor grad forholde meg til teknologisk tjenesteperspektiv som en helhet.

5.5 Nytt ved Åpen-edi kontra dagens EDI

Begge typer EDI har til hensikt å realisere et interorganisatorisk system som benytter informasjonspakker til informasjonsutveksling mellom de interne interorganisatoriske systemene. Noen av de viktigste nyhetene er som følger:

Bilaterale avtaler mellom de enkelte EDI-aktørene er ikke nødvendig ved bruk av Åpen-edi referansemodellen
Alle EDI-aktører melder seg på som rolleutøver i et eller flere scenarier, og gjør seg dermed kjent for andre EDI-aktører
Beskrivelsene av de teknologiske tjenestene scenariene baserer seg på er tilgjengelig for alle, og det vil høyst sannsynlig bli tjenesteytere som tilbyr de nødvendige produkter og tjenester.
Skiller operativt virksomhetsperspektiv og teknologisk tjenesteperspektiv slik at endringer i det ene ikke nødvendigvis fører til endringer i det andre. delvis nytt ved Åpen-edi referansemodellen.
Referansemodellen setter standarder som EDIFACT i perspektiv, og de skal kunne benyttes i kombinasjon med teknologiske tjenester.
Referansemodellen åpner for ny informasjonspakkedesign
Forhandlinger mellom de interne interorganisatoriske systemene vil være en naturlig del av utførelsen av et scenario.
Teknologiske tjenester vil tilby mekanismer for oversettelse av informasjonspakker. Disse blir blant annet realisert ved Basic Semantic Repository tjenester.

5.6 Oppsummering

Jeg oppfatter Åpen-edi referansemodellen å være ambisiøs i sine krav til teknologisk og virksomhetsmessig uavhengighet og interoperabilitet. Utviklingen av Åpen-edi referansemodellen oppfatter jeg som en top-down prosess hvor en tar for seg de overordnede problemer og forsøker å modellere og løse disse. En har foreløpig kommet frem til Åpen-edi referansemodellen som skisserer på et konseptuelt nivå hva Åpen-edi referansemodellen er tenkt å skulle bli. Komitéen som arbeider med Åpen-edi referansemodellen har så langt ikke sett på konkrete løsninger eller problemer knyttet til å realisere interorganisatoriske systemer.

I det neste kapitlet vil jeg se på en formell beskrivelsesteknikk for scenariobeskrivelser. Videre vil jeg i kapittel ni vurdere om Åpen-edi referansemodellen har mulighet til å nå sine egne målsettinger. Disse målsettingene at (i) det skal hurtig og kostnadseffektivt la seg gjøre å ta i bruk interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen (ii) Åpen-edi referansemodellen skal føre til stor utbredelse av interorganisatoriske systemer, (iii) Åpen-edi referansemodellen skal sikre at interne interorganisatoriske systemer som baserer seg på internasjonale standarder skal kunne spille sammen både teknologisk og virksomhetsmessig. Før jeg foretar vurderingen velge jeg en formell beskrivelsesteknikk, og prøver denne teknikken sammen med retningslinjer fra Åpen-edi referansemodellen på et transportscenario.

Tilbake til innholdsfortegnelsen