Vejledning i kravspecificering af Sag og Dokument standarder (Revideret udgave; januar 2011)

Transkript

1 Notat Vejledning i kravspecificering af Sag og Dokument standarder (Revideret udgave; januar 2011) Denne version af vejledningen er identisk med første udgave fra august 2010 bortset fra redaktionelle ændringer. 1. Indledning OIO-udvalget for sags- og dokumentområdet ønsker med dette notat at vejlede alle offentlige myndigheder i, hvordan man stiller krav om anvendelse af Sag og Dokument standarderne Målet med Sag og Dokument standarderne er: placere sags- og dokumenthåndtering i en sammenhæng, som definerer, hvilke roller og ansvar, en ESDH-løsning basalt set har og hvilke snitflader den har til omverdenen, således at løsningen kan indgå i de mønstre, som referencearkitekturen for sags- og dokumentområdet opstiller. at skabe forudsætninger for en bedre sammenhæng og klarere arbejdsdeling mellem ESDH-løsninger og fagsystemer. at skabe forudsætninger for at undgå dobbeltfunktionalitet mellem ESDH, fagsystemer og it-infrastruktur. at skabe forudsætninger for øget konkurrence på ESDH-markedet. 3. januar 2011 Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Side 1/11 OIO-komiteen har i december 2009 godkendt følgende standarder i regi af OIOudvalget for Sag og Dokument som anbefalede pr 1/1 2010: Generelle Egenskaber for serviceinterfaces på sags- og dokumentområdet Specifikation af serviceinterface for Sag Specifikation af serviceinterface for Dokument Specifikation af serviceinterface for Arkivstruktur Specifikation af serviceinterface for Klassifikation Specifikation af serviceinterface for Organisation I 3. kvartal 2010 sendtes følgende standard i OIO-høring: Specifikation af serviceinterface for Person Disse standarder afspejler den vedtagne referencearkitektur for sags- og dokument området. ITST har i 2009 gennemført Proof of Concepts, der har afklaret implementeringsløsning og anvendelsen af de generelle egenskaber. De ikke-funktionelle løsninger kan studeres i Vejledning om ikke-funktionelle krav vedrørende serviceinterfaces på sags- og dokumentområdet.

2 2. Standardernes virkemåde De 6 godkendte Sag og Dokument standarder er konstrueret som dataserviceinterfaces, dvs. de udstiller alene services til at modtage, opbevare og udlevere forretningsobjekterne Sag, Dokument, Arkivstruktur, Klassifikation og Organisation. Forretningsobjektet Person er i OIO-høring i 3. kvartal Standardoperationerne er Opret, Import, Passiv, Læs, Ret, Slet, Søg og List og er beregnet til system til system kommunikation. Dataserviceinterfacene kan anvendes hver for sig eller i kombinationer. For hvert af dem er specificeret, hvilke attributter, relation og tilstande, der beskriver en sag, et dokument, en arkivstruktur, en klassifikation eller en organisation. Gennem at stille krav om at alle en myndigheds it-systemer, som skal udbyde information om sager og dokumenter, forsynes med disse dataserviceinterfaces, vil det offentlige over tid opnå at it-systemerne i forskellige afdelinger og myndigheder vil kunne anvende informationer om sager og dokumenter på tværs af hinanden. Dermed overlades kommunikationen om sager og dokumenter til itsystemerne og man frigør tid til den faglige sagsbehandling (Dette er illustreret for kontanthjælpsområdet gennem en procesfortælling, der kan findes her: Side 2/11 Dette betyder, at man for ethvert system, der beskæftiger sig med informationer om sager, dokumenter, arkiver, klassifikationer, organisationer eller parter skal vurdere, om it-systemet skal kunne stille informationerne til rådighed for andre it-systemer, dvs. være serviceudbyder. Hvis de skal det, så skal man stille krav om at leverandøren monterer de relevante dataserviceinterfaces. Bemærk, at der ikke stilles krav til den indre struktur og opbygning af leverandørens it-system. Kun at det skal kunne danne den til dataserviceinterfacet definerede XML, og stille webservices til rådighed med flere eller alle standardoperationer. Dermed kan man også vælge at blive ved med at anvende implementerede systemer, der er velfungerende. De skal da alene tilføjes et eller flere af dataserviceinterfacene. Den til standarderne tilhørende XML kan findes via: Hvis it-systemet også skal anvende informationer om sager, dokumenter, arkiver, klassifikationer, organisationer eller parter, som hentes hos en serviceudbyder, så skal der stilles krav om at it-systemet skal kunne kalde operationerne i dataserviceinterfacene med de rigtige parametre og behandle den XML man modtager. Sag og dokument standarderne giver endvidere mulighed for: at udbrede fællesoffentlige dataservices for hvordan man udveksler oplysninger om sager og dokumenter delt op på få brede og velvalgte områder

3 at dataserviceinterfacene er anvendelige på alle itapplikationer, der skal kommunikere oplysninger om sager og dokumenter at det er muligt trinvist at implementerer dem over tid i takt med den offentlige organisations prioritering af opgaver at man ikke længere stiller krav til leverandørernes opbygning af deres software indenfor disse områder, men kun hvordan de skal udbyde og aftage dem mellem områderne 3. De enkelte standarders anvendelse Dataserviceinterfacet Sag udbyder information om sager, defineret som en samling af sammenhørende dokumenter og øvrige sammenhørende oplysninger, der i sit hele anvendes til at dokumentere en arbejdsproces og de afgørelser, der træffes undervejs i processen. Sagen mærkes med en relation til en klasse (også kaldet journalnøgle) fra et klassifikationssystem og til parter, aktører og arkiv. Dokumenter relateres til Sag gennem Journalposter. Sager har tilstande, der udtrykker sagens fremdrift. Er dit it-system et værktøj i en sagsbehandling, skal det enten kunne udbyde sine sager efter denne standard til andre eller anvende sager hentet i andre it-systemer eller begge dele. Side 3/11 Dataserviceinterfacet Dokument udbyder information om dokumenter, varianter og dokumentdele i form af metadata og selve dokumentet (fil), der kan være tekst, tegninger, grafik, fotografier, video, tale osv. Dokumenter har typer og tilstande, der udtrykker fremdrift, og kan have mange relationer til andre forretningsobjekter. Gemmer dit it-system dokumenter, der skal kommunikeres til andre it-systemer, skal det kunne udbyde sine dokumenter efter denne standard. Dataserviceinterfacet Arkivstruktur udbyder information om hvilke arkiver organisationen anvender, og for det enkelte arkiv udbydes informationer om arkivet, f.eks. hvilke aktører, der anvender det, hvilken klassifikation der skal anvendes, og i hvilken periode de anvendes. Herved sikres det, at sager og dokumenter, som er sagligt og logisk sammenhørende, men som befinder sig i forskellige itsystemer, kan håndteres samlet. Producerer dit it-system sager og dokumenter, som er afleveringspligtige til offentligt arkiv, skal it-systemet udbyde sin arkivstruktur gennem denne standard. Disse 3 standarder; Sag, Dokument og Arkivstruktur, giver tilsammen dataserviceinterfaces, hvor andre it-systemer kan gemme dokumenter organiseret efter sager og givet en arkivstruktur, der styrer den lovpligtige aflevering til offentligt arkiv. Det er muligt at have flere dataservices af samme art i organisationen, hvis det er hensigtsmæssigt. Med dataservices efter disse standarder kan andre itsystemer fokusere på at støtte afviklingen af forvaltningens arbejdsprocesser. Det er også muligt blot at oprette en dokumentcontainer forsynet med dataserviceinterfacet Dokument. I dette tilfælde styrer man så sager og arkivering i andre itsystemer og kan koble disse til Dokument interfacet gennem en proxyteknik (hvordan forklares i eksemplet i næste afsnit).

4 Dataserviceinterfacet Organisation udbyder information om en organisation i form af de følgende aktørtyper: Organisation (som juridisk enhed), organisatorisk enhed, organisatorisk funktion (svarende til rolle), it-system, bruger (person eller it-system) og interessefællesskab. Aktører udfører givne aktiviteter eller har ansvaret for at de udføres. Gemmer dit it-system information om aktører, som andre it-systemer kan anvende, skal it-systemet udbyde informationen gennem denne standard. Dataserviceinterfacet Klassifikation udbyder information om hvorledes et klassifikationssystem er opbygget og udleverer journalnøgler, klassemærker eller lignende, der udpeger specifikke klasser i klassifikationssystemet. Klassifikation kan anvendes til at udtrykke mange forskellige klassifikationssystemer, både komplekse journalsystemer og simple opdelinger med kun ét klasseniveau. Implementerer dit it-system en klassifikation, som andre it-systemer skal kunne benytte, skal it-systemet udbyde informationen gennem denne standard. Dataserviceinterfacet Person, der er i høring i 3. kvartal 2010, udbyder informationer om CPR-personer og personer uden dansk CPR-nummer. Formålet med standarden er at alle myndigheder, der administrerer personer med eller uden dansk personnummer, kan udbyde og aftage stamoplysninger gennem dette interface, således at der kun bliver én type dataserviceintegration om persondata at vedligeholde. Personer optræder som part i en sag, når sagens forløb vedrører personen. Implementerer dit it-system opbevaring og udlevering af personoplysninger, som andre it-systemer skal kunne benytte, skal it-systemet udbyde informationen gennem denne standard. Side 4/11 Disse 3 standarder kan anvendes af Sag, Dokument og Arkivstruktur, men er sandsynligvis også anvendelige for mange andre it-systemer, da de tilbyder informationer, der anvendes bredt i forvaltningens arbejdsprocesser. Da standarderne omhandler objekter, der alle er centrale i de fleste former for offentlig forvaltning, vil de være aktuelle for mange af de it-systemer, der findes hos de offentlige organisationer. Standarderne kan opbygges trinvist over tid, og resultatet vil efter en årrække betyde et højt niveau af interoperabilitet mellem sager og dokumenter i de offentlige organisationer. Det er derfor vigtigt at anvendelsen af standarderne er styret af organisationens it-strategi, der i samspil organisationens strategi og forretningsarkitektur fastlægger et strategisk mål for struktur og kommunikation mellem alle organisationens it-systemer. Lad os se på et eksempel på et sådant slutresultat. Er serviceudbyder i egen organisation indenfor eget sikkerhedsdomæne simplificerer dette aftale og kommunikationsform. Er serviceudbyder udenfor skal der træffes eksplicit aftale om adgang og kommunikation som i enhver anden type integration med eksterne parter.

5 4. Hvordan indføres standarderne i kravspecifikationer Krav til serviceinterfaces skrives som regel ind i den ikke-funktionelle del af kravspecifikationen under et afsnit om data eller integration. Kravene falder naturligt i tre grupper: 1. Den første specificerer, med hvilke parametre man kalder en service og hvad man får som resultat, inklusive struktur og format for begge. Dette er serviceinterfacets funktionalitet set fra it-applikationen, man bygger, og finders derfor også nogle gange som en del af de funktionelle krav. 2. Den anden specificerer med hvilke arkitekturegenskaber, man gennemfører kald og svarmodtagelse med. Det er krav til sikkerhed, kommunikation, driftsikkerhed og datakvalitet. 3. Den tredje er krav til hvorledes servicekaldene skal udvikles og testes. Side 5/ Kald af dataserviceinterfaces og format og struktur af resultatet Dette er hvad S&D standarderne specificerer, så det er dem man anfører. Men der er givet nogle frihedsgrader og valg, som man som kravstiller skal forholde sig til, og enten give som krav eller bede leverandøren om at komme med forslag til. Alt efter hvor meget spillerum det findes hensigtsmæssigt at overlade til konkurrence mellem leverandører i tilbuddet. Skal data fra en service udstilles, stilles et krav af denne form, hvor <Navn> angiver en af standarderne: Krav x: Løsningen skal implementere serviceinterfacet <Navn> således som det er beskrevet i standarden Specifikation af Serviceinterface for <Navn> med tilhørende XML og Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet og gennem brug af Vejledning om ikke-funktionelle krav vedrørende serviceinterfaces på sags- og dokumentområdet. Skal it-systemet anvende data gennem at kalde et af dataserviceinterfacene stilles et krav af denne form: Krav y: Løsningens skal kunne kalde følgende operationer med de rette parametre i dataserviceinterface <Navn>, således som det er beskrevet i standarden Specifikation af Serviceinterface for <Navn> med tilhørende XML og Generelle egenskaber for serviceinterfaces på sags- og dokumentområdet og gennem brug af Vejledning om ikke-funktionelle krav vedrørende serviceinterfaces på sags- og dokumentområdet. Løsningen skal kunne modtage og fortolke den XML, som dataservicen returnerer. De generelle egenskaber er meget vigtige at have med, da specifikationen ikke kan stå alene idet den bygger videre på de generelle egenskaber. Det er derfor også vigtigt, at man som kravstiller forstår de generelle egenskaber og derigennem forstår muligheder og begrænsninger i standardernes dataserviceinterfaces og

6 som kravstiller foretager valg, der hvor de er mulige. De valg man foretager skal leverandøren beskrive i en servicebeskrivelse for dataservicen. Man kan f.eks. vælge ikke at implementere nogle af serviceoperationerne eller nogle af de valgfrie datafelter. Gør man dette skal kravet detaljeres med disse valg således: Servicesinterfacet <Navn> skal implementeres med følgende operationer:,,,,. De i standarderne specificerede operationer er helt basale operationer: Opret, Importer, Læs, Ret, Slet, Passiver, Søg og List. Input til disse er en struktur med et objekt, dele heraf eller et søgekriterium. Output fra disse er en struktur med resultatet. Inputstruktur og outputstruktur skal fastlægges enten af leverandøren eller gennem kravene. Til Søg skal kravstiller afgøre, hvilke søgekriterier der er behovet hos serviceaftagere og til List hvilket listestrukturformat man afleverer i: Servicesinterfacet <Navn>, operation Søg, skal implementeres med følgende søgekriterier:,,,. Servicesinterfacet <Navn>, operation List, skal implementeres med følgende listestruktur som output:. De generelle egenskaber indeholder en beskrivelse af egenskaben dobbelthistorik med både registreringstidspunkt og virkningstidspunkt. Registreringstidspunktet er det tidspunkt, hvor forretningsobjektet er lagret. Denne registrering sker ved oprettelse og ved hver operation, der ændrer objektet. Virkningstidspunktet angiver de tidsperioder, i hvilke værdierne i objekternes attributter, tilstande og relationer har virkning. Side 6/11 Virkningstidspunktet anvendes til at angive ændringer både frem i tiden og tilbage i tiden, og kan dermed anvendes til opbevare en historik, planlægge fremtidige hændelser eller generere advis eller notifikationer. Da implementeringen af brugen af dobbelthistorik er kompleks, er den ikke obligatorisk, og man skal som kravstiller derfor tage stilling til, om det giver gevinster nok i forhold til arbejdsprocessens automatisering. Resultatet skal indføjes i kravet således: Servicesinterfacet <Navn> <skal kan skal ikke> leveres med dobbelthistorik. De generelle egenskaber fastsætter, at hver gang der sker en objektregistrering, skal objektet udstede en hændelse, der specificeres som beskrevet i de generelle egenskaber. Men da denne beskrivelse er ret generel skal kravstiller specificere det nærmere. Der findes hos ITST konkrete eksempler på implementeringen heraf og en vejledning forventes i 4. Kvartal Servicesinterfacet <Navn> skal ved hver objektregistrering udstede en hændelse struktureret som beskrevet af ITST i vejledningen 4.2 Specifikation af ikke-funktionelle krav Vejledning om de ikke-funktionelle krav beskriver løsningsmuligheder og anbefalinger for følgende arkitekturegenskaber: Sikkerhed og brugerstyring Integration og kommunikation Driftsikkerhed

7 Information og data Man kan vælge at anføre disse samme sted som servicefunktionaliteten over for, eller i de afsnit af kravspecifikationen, der omhandler disse egenskaber S&D Referencearkitekturens mål er at sikre interoperabilitet om kommunikation af sager og dokumenter på tværs af alle it-systemer i det offentlige, fagsystemer, processtyringssystemer som ESDH-systemer. Derfor vil dette økosystem være distribueret og sammensat af produkter fra forskellige leverandører, og derfor skal sikkerheden kunne håndtere denne distribution, dvs. være føderal. Dette betyder at hvert sikkerhedsdomæne kan have forskellige bruger- og rettighedshåndteringer, men at man kan sende viden om en brugers akkreditiver med til den serviceudbyder, der leverer svaret, efter en fælles standard. Afsnittet om ikke-funktionelle krav i vejledningen beskriver hvorledes man implementerer dette og hvilke fællesoffentlige OIO standarder man kan anvende. Servicesinterfacet <Navn>, som <kaldes indenfor dette sikkerhedsområde kaldes mellem sikkerhedsområderne og > skal anvende denne sikkerhedsmodel:. Side 7/11 S&D standarderne giver semantisk interoperabilitet, dvs. de sikrer at betydningen af servicekald og servicesvar er veldefinerede og ens for alle. Men hvordan servicekald og servicesvar transporteres er indenfor et sikkerhedsdomæne valgfrit og mellem sikkerhedsdomæner valgfrit inden for de fællesoffentlige OIO standarder. En S&D dataservice, der vil blive anvendt meget, vil blive kaldt fra flere forskellige typer it-systemer. Her skal kravstiller sikre at man ikke indfører stramme bindinger til én protokol, men sørge for at man som serviceudbyder driftseffektivt kan håndtere flere protokoller. Det anbefales at man altid implementerer en SOAP interface, for dermed at sikre at ens service er tilgængelig via denne protokol. Man skal også tage stilling til forretningsprocesserne omkring kommunikationen kræver pålidelighed og/eller uafviselighed af transporten, idet dette ikke er berørt i S&D standarderne. Vejledningen indeholder et skema til systematisk valg af kommunikationsprofil. Servicesinterfacet <Navn> skal implementere en kommunikation baseret på SOAP samt kommunikation<er> baseret på profil<erne> <,,> beskrevet i Vejledning om ikke-funktionelle krav vedrørende serviceinterfaces på sags- og dokumentområdet, afsnittet om Integration og kommunikation. De følgende afsnit i vejledningen om ikke-funktionelle krav indeholder en række vigtige implementeringsanbefalinger omkring caching, versionsstyring, hændelser og servicebeskrivelser, driftsikkerhed, håndtering af referenceintegritet og datavalidering, som kravstiller skal gå igennem og formulere krav om eller instruere leverandøren om at komme med bud på. 4.3 Specifikation af udvikling og test af servicekaldene Når det er nødvendigt for kravstiller at forholde sig til dette emne, så skyldes det at erfaringerne fra de senere år med at implementere integrationer mellem leve-

8 rancer fra forskellige leverandører viser, at der er en række forhold, som man skal være meget opmærksom på, hvis man ikke vil løbe ind i problemer og forsinkelser. En vellykket integrering og test kræver at kravstiller kan forsyne begge parter i en integration med de relevante informationer omring både implementeringsvalg i servicekald og servicesvar og om de ikke-funktionelle valg man tager. Dernæst skal kravstiller kunne styre et nøje tilrettelagt testforløb, der gradvis bygger transporten og de andre ikke-funktionelle løsninger op og derefter lægger dataudvekslingen på. Dette inkluderer at man har de rette teststubs til stede med fornuftige og repræsentative datamængder, og senere har rådighed over de rette testmiljøer og præproduktionsmiljøer på de rigtige tidspunkter. Fælden ligger i at kravspecifikationen er rettet mod den ene leverandør, som leverer den nye applikation eller service, mens man ofte glemmer reelt at inddrage den anden leverandør, som man skal integrere op imod. Derfor skal man være eksplicit i sin kravspecifikation om, hvem det er, der har arbejdet med at sikre at den anden leverandør er velinformeret, bliver inddraget i udvikling og testforløb og leverer de aftalte ydelser til rette tid. Det vil enten være kravstillers egen itorganisation hvis de har kompetencen, eller integrationsrådgivere, som er specialiseret sig i denne form for integrator-rolle, som kravstiller hyrer ind. Side 8/11 Denne del af kravspecificeringen skal med helt frem i planlægningen og være en del af business casen, og detaljeres efterhånden som løsningen konkretiseres, idet erfaringen viser at emnet både koster kalendertid og arbejdstid såvel hos kravstillers ressourcer og evt. også hans rådgiveres ressourcer, såvel som hos den 3. Part, der har leveret det system, man skal integrere til. 5. Et eksempel: Standardernes anvendelse på kontanthjælpsområdet Forvaltningen af kontanthjælp foregår i et samspil mellem et Jobcenter, der registrerer ledighed og udarbejder en jobplan, et Servicecenter, der behandler ansøgning om kontanthjælp og en Jobbro, der udarbejder en aktiveringsplan, og følger op på om den overholdes. Eksemplet er hentet fra den ovenfor omtalte procesfortælling og procesdiagrammet i Bilag 2 illustrerer eksemplet. Følgende procesdiagram er et udsnit fra dette bilag.

9 Side 9/11 I dette eksempel har organisationen arkitekturprincipper, der bestemmer, at fagsystemer fokuseres på at støtte sagsbehandleres arbejdsproces bestående i at kende og fortolke de relevante regler for området. Derfor gemmer fagsystemerne ik-

10 ke dokumenter, der skal anvendes af andre. I stedet anvendes en fællesservice for sags- og dokumentopbevaring, som er forsynet med dataserviceinterfaces Sag, Dokument og Arkivstruktur. Det er denne, der kaldes en ESDH-kerne. Et andet arkitekturprincip er, at fagkyndige sagsbehandlere ikke sættes på sager, før organisationen er sikker på, at den igangsættende part i sagen har leveret de oplysninger og forudsætninger, der skal til for at sagsbehandleren kan arbejde. Det betyder, at en medarbejder i modtagelsen af en borger står for at oprette sagen og tjekke oplysninger og forudsætninger. Til dette anvender medarbejderen et sagsmodtagelses it-system, der anvender en række fællesservices gennem standarderne for sag og dokument: 1. Dataservicen Person på fællesservicen Stamdata anvendes til at kontrollere borgerens oplysninger om sin identitet gennem personnummeret 2. Dataservicen Klassifikation på fællesservicen KLE klassifikation anvendes til at finde den journalnøgle, som sagen skal have 3. Dataservicen Organisation på fællesservicen Myndighedsdata anvendes til at finde hvilken sagsbehandler, der skal sættes på sagen. Det er muligt, fordi organisationen i opbygningen af fællesservicen har opmærket sine organisatoriske funktioner og/eller enheder med hvilke KLE emner, de kan forvalte. 4. Endelig oprettes sagen i ESDH-kernen gennem dataserviceinterfacet sag, hvor den tildeles et unikt UUID og efterfølgende oprettes i det relevante fagsystem med det samme UUID, således at begge it-systemer har den samme fælles reference Side 10/11 Oprettelsen i Jobcentrets fagsystem notificerer den fagkyndige sagsbehandler, der går i gang med at behandle sagen. Når der undervejs produceres dokumenter, som skal gemmens, gør fagsystemet det gennem serviceinterfacene Sag og Dokument på ESDH kernen. Skal fagsystemet senere præsentere dokumentet hentes det via Dokument. På samme måde etableres samspil mellem ESDH-kernen og de andre fagsystemer i hele kontanthjælpsprocessen. Herigennem udnytter de forskellige fagsystemer ESDH-kernen til at opbevare og dokumentere sagsforløbene gennem system til system kommunikation, så dette arbejde ikke skal udføres manuelt. Samtidig friholdes fagsystemerne fra denne opgave, så de kan fokusere på at støtte arbejdsprocessen og dermed kan kompleksiteten af dem mindskes. Organisationen er nået frem til denne fordel ved at stille krav om implementering af sags- og dokumentstandarderne efterhånden som it-systemerne i organisationen moderniseres, fornyes eller indføres. Udgangspunktet for, hvornår implementeringerne sker, afgøres i takt med hvornår organisationen giver fokus og ressourcer til de forskellige forvaltningsprocessers digitalisering og modernisering. Det er helt centralt at forstå, at datastandarderne kan anvendes enkeltvis som det passer ind i det forløb af projekter, som følger organisationens forretningsprioriteringer. Som omtalt tidligere kan man som startpunkt vælge at oprette en fælles dokumentcontainer for alle organisationens eller organisationsenhedens arbejds-

11 processer. Gennem at anvende en proxyserver kan man forbinde sig til eksisterende implementeringer af sager, parter eller aktører, som ikke endnu er forsynet med dataservicestandarden. Der er tale om en simpel proxyserver, som danner en mapning mellem de UUID er for forretningsobjekter, som S&D standarden kræver og de unikke identifikatorer i den eksisterende implementering. Ad denne vej kan man anvende en standard dokumentdatabase, der kan håndtere de medier som er aktuelle for organisationen, ved at påmontere dataserviceinterfacet Dokument på standardsystemet. Måske vil man oprette en separat dokumentcontainer for videosekvenser, hvis man kan købe en standard database herfor forsynet med streamingfaciliteter. Så skal man blot montere dataserviceinterfacet Dokument herpå også. Senere kan man så erstatte proxy med et dataserviceinterface, der igen kan starte simpelt med få operationer, og udbygges efterhånden som forretningsrelevansen er der. Så man kan realisere S&D standarderne trinvist og man kan efterleve andre arkitekturprincipper end dem som procesfortællingen heri er bygget op om. Man kan f.eks. afgøre, at det er mest hensigtsmæssigt for arbejdsprocessen i et fagområde, at fagsystemet gemmer sager og dokumenter for dette område, samtidig med at informationerne skal være tilgængelige for andre arbejdsprocesser i forvaltningen. Det medfører at man skal tilføje en eller flere af dataserviceinterfacene Dokument, Sag og Arkivstruktur til dette fagsystem, og dermed gøre sagsbehandlingens informationer tilgængelige for andre it-systemer, såsom fx ESDH-systemet. Side 11/11