Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor. Generelle tilbakemeldinger som er diskutert i dokumentgjennomgangsmøte: Rapporten er et meget omfattende survey som gir en god gjennomgang av området. Dokumentet har en pragmatisk tilnærming til området, der for eksempel ytelsesmessige problemstillinger også står i fokus. Konklusjonene på anbefalinger i kapittel 5 er uproblematiske i forhold til våre valg og synspunkter. Det er et godt initiativ at det settes sammen stacker eller pakker av anbefalinger fra WS-1. (kap 3.1.3). Vi ser, umiddelbart, ingen konflikter mellom dokumentets innhold og vårt sikkerhetsarbeide. Vi ber om tilbakemelding på hva det vil si at en standard gjøres anbefalt eller obligatorisk. Hvilke og hvor sterke føringer legger dette opp til? Gjelder det først og fremst kommunikasjon ut og inn av en etat eller gjelder det også internt i etatene? (jfr diskusjoner om arkitektur-prinsipper i Difi-møte 29.okt.) Vi ønsker en klarere formulering av hva som menes med tjenesteorientering. Det virker som det i noen grad er en sammenblanding av tjenesteorientering som prinsipp (ref [19] Overordnede IKT-arkitekturprinsipper for offentlig sektor), og konseptet tjenesteorientert arkitektur (SOA) med tilhørende begreper/standarder/teknologier. (for eksempel figurene på side 9, kap 3). Prinsippet tjenesteorientering gir føringer for å sikre at brukerne av offentlige tjenester for tilgang til tjenester og informasjon der de trenger det. SOA er et konsept og tankegods som er rettet for å forvalte og utvikle de underliggende IT-systemene i en virksomhet i forhold til virksomhetsmessige føringene som finnes (og der gjerne prinsippet tjenesteorientering er et av disse) Vi synes det legges noe for stor vekt på direkte databaseintegrasjon, sql-grensesnitt, etl/filoverføring og liknende. Slike grensesnitt kan nok sees på som tjenester hvis man ser stort på det, men er neppe innenfor det vi ser på som tjenesteorientert teknologi. (bl.a. 3.4.1, 3.4.9, 4.2.1 alt 2. med mer.) Kapittel 4 beskriver på et nokså høyt/enkelt nivå forskjellige metoder og forhold som vedrører tjenesteorientering, mens kapittel 3 som beskriver standardene ligger på et vesentlig lavere/teknisk nivå. Vi ønsker at sammenhengen mellom informasjon i disse to kapitlene kommer noe klarere frem. Videre: Vi foreslår at kapitlene bytter plass. Kapittel 4 bør åpenbart leses før kapittel 3. Vi synes det er lagt opp til et noe kunstig skille mellom saksbehandling og innrapportering. Vi mener det strengt tatt ikke er noe vesensforskjell på en sak som behandles automatisk og en innrapportering av grunnlagsdata som behandles automatisk. Figur 11 antyder at innrapportering går rett inn i registeret mens saksbehandling går via informasjonsutveksling. Dette er nok for sterkt forenklet. Vi savner noen offentlige aktører i arbeidsgruppa, spesielt Altinn.
Under følger en oppsamling av tilbakemeldinger på spesifikke punkter i rapporten. Tilbakemeldingene kommer i utgangspunktet fra enkeltmedarbeidere i SKD/SITS og representerer ikke nødvendigvis et omforent resultat av diskusjon/gjennomgang. 4.1 behov/ krav Ønsker og krav om graden av lokal datalagring/redundante data vil også i stor grad påvirke de tekniske løsningene 4.2.1 tekniske løsninger for databaseintegrasjon Løsningene kan settes opp med minimal koding. -> Det vil som regel eksistere såpass spesifikke behov at dette i realiteten ikke stemmer. 4.2.2 Løsninger for søk Å foreslå å ha åpne søkegrensesnitt som kan ta i mot forespørsler i SQL er meget riskabelt med hensyn på ytelse, og bør ikke eksponeres ut av en virksomhet. 5.4 Områder for videre satsning Ser ikke helt en rød tråd i de foreslåtte satsningene i forhold til det som er scope for dette dokumentet. Figurer med komponenter og kommunikasjonsveier i kap 3 og 4 Vi har noen innsigelser mot noen av linjene/figurene som er satt opp. Ikke alltid riktig forenklet. Dette kan eventuelt diskuteres. 5.1 Anbefalte standarder WSDL20 kan godt foretrekkes foran WSDL11 20 da det kan gi mer åpenhet. Er dog ikke med i anbefalt stack fra WS-1 (kap 3.1.3). 4.3.5. Arkivering Det er vesentlige forskjeller på NOARK-4 og NOARK-5- standardene både prinsipielt og i praksis. Dette burde fremgå av teksten. 3.5 Portaler, interaksjon og presentasjon 3.6 Samhandling, prosesser og komposisjon av tjenester Mye på standarder, og litt for lite om muligheter / visjoner i bruk av dem. Mye på standarder, og litt for lite om muligheter / visjoner i bruk av dem. 3.9.2.1 BPMN Generell kommentar rundt konvertering fra BPMN til BPEL. Utfordringene er som for all kodegenerering, det er vanskelig å vedlikeholde i ettertid fordi den implementerte prosessen har mye mer enn designet inneholder. 4.1 Informasjonsutveksling (4.1.6) Diskusjonen kan med fordel utvides til å bestemme hvilket system som er master, eller å sørge for at det er en master for ett sett med data (en melding). Videre protokollen beskrives slik at andre systemer kan forstå hva systemet gjør. Savner diskusjon rundt meldingsutforming og avveining
mellom transaksjonell (alle data som endres i en transaksjon, eller business event sendes som en melding) vs. objekt (data sendes i hver sine meldinger, en for person, en for adresse etc.). Utforming betyr mye for arkitekturen, bruk og tolking av meldinger. 4.2.1 tilgjengeliggjøring av registerdata Tekniske løsninger 4.3.3.1 Portabilitet mellom prosessmotorer Ulempene med å kopiere registre kommer ikke fram. Sentral og viktig logikk må ved bruk av denne metoden vedlikeholdes på forskjellige steder. Det er stor risiko for at data blir brukt feil eller kommer på avveie. Her bør det vektlegges sterkere at implementasjon inneholder unntak, feilhåndtering og tekniske detaljer som vanner ut den visuelle kommunikasjonen som man ønsker i en prossessbeskrivelse. 4.3.4. Interoperabilitet mellom fagsystem Pass på å balansere funksjonalitet i prosessen (på utsiden) og fagsystemet. Det er ikke bra å ha for mye data kopiert ut i prosessen. Gode tjenester bør i tilfelle lages i fagsysemet framfor å kopiere ut i prosessen. Kopiering av data er også en indikasjon på at logikk er på feil sted. Det er vanskeligere å migrere til ny versjon av en prosess, hvis den har mye data eller funksjoner. Også fordi det er mer som kan forårsake en oppgradering. GUI interoperabilitet. Det bør stå mer om at web som plattform med noen arkitekturvalg danner basis for interoperabilitet på GUI nivå. Man trenger ikke en Portal for å få til det. 4.3.5 Arkivering Uenig. Saksbehandling og Journalføring (arkiv) bør sees på uavhengig. På sikt vil fler og fler prosesser gå over fra manuell saksbehandling til automatisert, samtidig som dokumentene erstattes med xml. 4.4 Innrapportering Dette er midt i det vi gjør rundt Modernisering av grunnlagsdata. Vi anser tett kommunikasjon mellom oppgavegiver og mottaker (oss) som en forutseting for kvalitet. Med tett kommunikasjon menes at oppgavegiver sender inn og får svar i løpet av minutter på om det som er sent inn er gyldig. Tett kommunikasjon gir også mindre topper og dermed mindre behov for skalerbarhet og store batch-jobber. 4.5 Arkitektur samhandlingslagets prosesser og regler kan brukes til å sette sammen tjenester uten programmering Uenig, man kan ikke lage systemer uten programmering. BPEL er også programmering. Det å realisere en Portal er ikke synonymt med Portalprodukt. Brukerdialogintegrasjon eller -samhandling handler om web og noen arkitekturvalg. Det er lettvekts.
Vil heller kalle dette en felles plattform for brukerdialogintegrasjon, enn en portal. Oppsummert Hovedfokus er kanskje: Gode og transportable dataformater (meldinger) Gode og tilgjengelige tjenester. Tjenesteorientering er ikke bare teknologi, men også en måte å konstruere systemene på. De skal kunne samarbeide i stedet for å være selvberget. Generelt Generelt Litt dokumentteknisk småplukk: - dokumentet er ikke i versjon 1.0 enda - det mangler versjonshistorikk og endringsbeskrivelser - vurder å flytte innholdslista til etter sammendraget Det er uklart i hvilken grad andre større offentlige aktører har vært involvert i arbeidet. Blant annet NAV og Brønnøysundregisterne (ved Altinn II-prosjektet) jobber mye med arkitektur og vil kunne bidra med gode innspill og kvalitetssikring. 1 Sammendrag Forskjellen mellom prinsippet tjenesteorientering og SOA som tankegods bør presiseres allerede her. 2.1 Bakgrunn Liste med 7 kulepunkt, i teksten rett etterpå står i tillegg til de seks andre over.. 2.1 Bakgrunn, siste avsnitt Bra og her bør det også presiseres at SOA er et tankegods/konsept for arkitekturarbeid, altså for hvordan man går fram for å lage systemer. Prinsippet tjenesteorientering i kulepunkt-lista treffer på et høyere nivå, dette er prinsipper på virksomsomhetsnivå. 2.4 Viktige begreper Avsnittet må strammes opp samme tema som tidligere kommentarer rundt forskjellen på prinsippet tjenesteorientering og SOA som arkitektur-tilnærming. 3 Metoder og 1) Skille ut teksten som starter med Ekisterende løsninger og organisatorisk modenhet fram til 3.1 som eget kapittel 3. Resten av nåværende kapittel 3 blir kapittel 4. Denne første teksten beskriver på et veldig overordnet nivå forslag til konkret arkitektur ( løsningsarkitektur ) for det offentlige dette bør skilles klart fra teknisk arkitektur og generelle metoder (som er hovedfokus for dette dokumentet). Kap 3, siste avsnitt side 10 2) Altinn må plasseres tydelig i figurene. Satt på spissen gjør Altinn det mulig for en virksomhet å støtte prinsippet tjenestorientering uten å ha noe forhold til SOA i egen virksomhet Stryk setningen Et slik målbilde kan også flytte dagens Setningen kommer litt tilfeldig og er utenfor kontekst i dette dokumentet.
3.2.1 Ulike typer mellomvare Endre første setning til Skillet mellom applikasjonsintegrasjon (EAI) [9] og teknologien som støtter tjenesteorientert arkitektur 3.2.1 JCA bør behandles her er i større grad mellomvare enn ren databaseintegrasjon 3.2.2.1 Trend at UDDI mer viktig design time enn runtime i SOA bør beskrives her. 3.4 / 3.4.1 Må strammes opp databaseintegrasjon har lite å gjøre i en SOA-modell 3.4.1.1 Tas vekk eller endre beskrivelsen i retning at databaseintegrasjon medfører for tett binding både teknisk og logisk 3.4.1.2 Setningen sammenkobling på dette nivået gir økt overhead er misvisende (om ikke feil..) integrasjon på databasenivå kan gi høyere effektivitet så lenge alle lag er på samme fysiske maskin men databaser skalerer dårlig og så lenge man har fysisk lagdeling og nettverkstransport betyr ikke overhead en innført ved en ESB så mye 3.4.2.5 Føderasjoner Vanskelig avsnitt bør skrives om og forenkles (mer konkrete eksempler?) 3.4.9 Databaseintegrasjon Setningen (siste avsnitt side 29) til dels kan dette også være alternative krever et tillegg: på bekostning av bindinger, dårligere vedlikeholdbarhet og manglende skalerbarhet 3.4.9 Vurdere å skrive om hele avsnittet dette er ikke en anbefalt design-strategi i en SOA. Kap 4 Figur 11 bør omarbeides 1) innrapportering er også saksbehandling. 2) Etatene har ikke registre i form av databaser, de har fagsystemer som understøtter saksbehandling 4.2.1 For databasesentrert - det er et poeng nettopp ikke å integrere på databasenivå. Databasenivå-integrasjon bryter med prinsippet om løs kobling på flere nivåer, eksempelvis utvekslingsformater, transportprotokoll og ikke minst funksjonelt (ren datautveksling krever duplikasjon av funksjonalitet) 4.2.2 Avsnittet bør skrives om. Søkefunksjonalitet må pakkes inn i tjenester for å kunne kontrollere både ytelse og (kanskje spesielt) sikkerhet/tilgangskontroll generell databasetilgang er ikke ønskelig, selve om språket er standardisert gjennom SQL eller XQuery eller andre varianter. 4.3.5 Bør vises til arbeidet rundt NOARK-5 der det tydelig sies at arkivdanning ikke er det samme som saksbehandling eller saksprosess. Standardisering rundt saksbehandling bør jobbes mer med (SGK er antakelig ikke tilfredsstillende) 4.3.6 Siste avsnitt; andre setning. Altinn er rettet like mye mot det private/den enkelte innbygger som det er rettet mot næringslivet. 4.4.2 Første avsnitt: argumentasjonen er ikke helt bra her kanskje direkte feil. Altinn II er bygget på SOA-prinsipper og gjennomgående bruk av åpne standarder for integrasjon. Det burde vise at ekstrem belastning i seg selv ikke gir argumentasjon for å gå vekk fra (åpne) standarder.
4.4.2 Andre avsnitt; dette kan (og vil bli tolket som) at åpen kildekode ikke kan brukes der det er krav til ekstrem ytelse. Dette er direkte feil. Blant annet er åpen kildekode i stor grad tatt i bruk for systemer med ekstrem ytelse i bl.a. de store globale handelsbankene. Det er i OSS-miljøet at tekniske løsninger og design-mønstre for denne løsninger har oppstått ikke hos de store leverandørene av proprietære løsninger. 4.4.2 Krav til sikkerhet (autentisering, autorisering, meldingssikkerhet mv) bør være en direkte begunnelse for også hvor de små aktørerene i (hele) offentlig sektor bør ta i bruk Altinn. Vi kan ikke forvente at andre enn de store klarer å implementere gode nok løsninger på egen hånd. 4.5 figur 12 Fjern databasesymbolet fra figuren på det nivået vi bør behandle (i kontekst SOA) så finnes ikke databaser, de er innkapslet i komponenter (som inneholder data og logikk). 4.5 punktliste side 66 Kulepunkt 1 og 2 må fjernes. Kulepunkt 3 kan beholdes med en presisering om at dette er tjenester som gir mening i virksomhetens sammenheng. 5.4.2 Tjenester i skyen Bør utdypes noe mer spesielt er selvbetjeningsaspektet et poeng i Cloud-tankegangen; forbrukeren av tjenester avgjør selv hva og når tjenesten tilbys umiddelbart og uten manuell behandling. Mvh Erik Hilmen Seniorrådgiver SKD/SITS/UTV