Loading…
Tilbage

Hvad mener du om de 15 skarpe?


IT- og Telstelstyrelsen har sammen med OIO komitéen udarbejdet et debatoplæg med 15 skarpe best practice anbefalinger for digitalisering. Anbefalingerne bygger på konkrete erfaringer og sætter skarpt på en række af de udfordringer mange digitaliseringsprojekter står i.

Er du enig? Hvad er dine erfaringer? Deltag i debatten om de 15 skarpe anbefalinger til digitalisering af Danmark. Debatten foregår her på denne side.

De 15 skarpe er:
1. Få styr på forretningsgangene.
2. Anvend fælles forretningsterminologi.
3. Brug open source-software ved egenudvikling.
4. Brug fleksible udviklingsmetoder.
5. Dataudveksling skal anvende fælles datastandarder.
6. Offentlige portaler skal hænge sammen.
7. Webservices skal være nemme at finde og anvende.
8. Webservices skal kunne tale sammen.
9. Brug digital signatur og single-sign-on.
10. Basér indkøb og salg på den fælles infrastruktur for handel.
11. Brug fælles sprog på sags- og dokumentområdet.
12. Stil krav om åbne standarder.
13. Skab sikre løsninger.
14. Få styr på it-arkitekturen med metodik.
15. Del viden og samarbejd på tværs.

Læs mere og download pjecer om anbefalingerne på OIO Arkitekturguiden: http://ea.oio.dk/arkitekturkrav

På baggrund af debatten vil vi revidere principper og anbefalinger og en ny version vil blive lanceret på it-arkitekturkonferencen den 1.-2. april 2009.
Profilbillede

Kom nu ind i kampen!!

Kristian K. Hansen

Der kan siges meget om de 15 skarpe og det vil jeg undlade men det er til at skrige over at man ikke kan bruge sin digitale signatur på jeres nye flagskip: Digitaliser.dk


- Helt ærligt det kan sku ikke være rigtigt


VH


Kristian

Kaere Stefan

Det er noget sludder!

1. Vi har, de facto, en digital signatur uanset om den overholder lovens krav.

2. En login mulighed via ovenstaaende ville ikke paa nogen maade begraense andres muligheder for at diskutere paa portalen.

Hilsen

Kristian 

Det er dog ufatteligt at du vil fratage mig muligheden for at anvende min signatur, som jeg er glad for, uden at det fratager dig nogle muligheder ??

Jeg tror at det er nytteloest at vi to diskuterer sagen overhovedet.

Hej Kristian

Du har helt ret, så enkelt kan det vist siges!
Vi har haft en agil udviklingsproces (også en af de 15 skarpe...) hvor vi løbende har vurderet features og indtil videre har vi prioriteret andre ting højere, men det er sat på skemaet i løbet af de næste par sprints, så jeg håber meget du snart kan logge på via NemLogin, det bliver selvfølgeligt et tilvalg!
Vh
Christian Lanng (som er inde i kampen!) ;)

 

 

 

 

 

[slettet indlaeg]
[slettet indlaeg]
[slettet indlaeg]
Profilbillede

Hvad med ophavsretten?

Jarl Friis

Generelt synes jeg ikke de 15 punkter er særlige "skarpe", jeg synes tværtimod de er meget uklare og tvetydige.

fx. punkt 3
Det er lidt meningsløst at snakke om at "bruge" open source software ved egenudvikling. Enten "bruger" man noget som findes i forvejen, eller også udvikles der noget nyt.

A) Enten menes der "brug en open source licens" ved egenudvikling
eller
B) brug open source udviklingsværktøjer ved ved egenudvikling.
eller
C) Stil krav om open source licens når der specialudvikles (af ekstern leverandør)

Når der er tale om egenudviklling (dvs. udvikling sker af offentlige ansatte), så synes jeg det er en glimrende ide at udgive det under en open source licens således at andre offentlige institutioner kan få glæde af det og spare os alle for en masse skattepenge.

Hvis der menes "brug open source udviklingsværktøjer ved ved egenudvikling", så synes jeg at anbefalingen er fuldstændig værdiløs. Hvad er rationalet i at vælge et open source udviklingsværktøj frem for et kommercielt, hvis en udvikler er mere effektiv med et kommercielt værktøj.

Hvis der er tale om indkøb af software (specielt timebaseret afregning), synes jeg at en offentlig indkøber bør stille et endnu højere krav end at licensen skal være open source. Nemlig et krav om at ophavsretten skal tilhøre den offentlige indkøber. Således kan den offentlige indkøber nemlig selv bestemme hvilken licens det kan/skal udgives under. og i følge ovenstående (A) anbefales det at udgive det under en open source licens, så det kan spare os alle for en masse penge.

Jarl
Profilbillede

Asim Hanif

Asim Hanif

Hej til alle!


Interessant diskussion.


Mit grundliggende spørgsmål er om de her 15 skarpe er resultatet/leverancen af Fællesoff. Arkitekturkrav-projektet??? Hvis ja, så synes jeg at de ikke rigtig kan kaldes for krav, da de er er alt for overordnende til at kunne anvendes i fx. kravspecifikationer. Det er mere opsamling af kendt OIO-viden.


Derudover synes jeg at der mangler sammenhæng til de 5 hvidbogsprincipper, SOA-pjecens principper og de nye 10 principper. Man bliver ret forvirret som praktisk bruger af dette OIO-arbejde.


Af samme skuffe; vil jeg igen spørge om den konkrete, formelle og praktiske sammenhæng mellem OIO EA, FORM og nu STORM???


Nu skal man falde til ro og komme med flg. feedback til de skarpe:


3. Open Source


Her er jeg helt på linie med Rene Løhdes feed back. Hvor har det ladet sig gjort praktisk ud over lidt hos E&S?? Det med OS og genbrug på tværs vil først lade sig gøre med Governance og mekanismer til incitimenter.


Hvis man virkelig ønsker dette fra ITST, skulle de komme med konkrete forslag hvorledes man fx. lave en option i sin kravspecifikation om at en løsning skal baseres på OS og være frit tilgængelig på Softwarebørsen. Så kan man se den reele merudgift ift. proprietær platforme.


4. Fleksible udvekslingsmetoder


og alt den historie med vandfald osv. Folk i vores situation fortæller hvor svært det er med noget iterativt ift. de eksistererende kontraktparadigmer og udbudsregler. Teoretikere fortælller om Konkurrencebaseret dialog og Rammeaftaler. Vi siger; ja ja. - Hvor mange har erfaringer med Konkurrencebaseret dialog?. Denne udbudsform kræver enorm stort effort hos Kunden og Leverandøren. Hos kunden; kræver det måske op til dobbelt så stor en effort (+ risikoen pga. man ikke har prøvet det før); hvis man laver Business case på det; så tror j man bliver klogere ift. merværdien.


kh. Asim Hanif:-)


 


 

Profilbillede

En effektiv & skarp tjekliste!

Peter Huber

Fine og forståelige råd, der kommer rundt i mange digitaliseringsproblemstillinger.

I bilaget kunne I med fordel sætte fokus hvor de enkelte skarpe relaterer til på OIO EA reolen nogen hører til under Principper, andre under Forretning, Information, Applikation etc.

Til et par af de skarpe har jeg følgende forbedringsforslag:

1) "Forretningsgange" - skulle måske være "forretningsprocesser", som det hedder i OIO EA. Eller det kan dokumenteres som nævnt ovenfor.

4) Vigtigt at få påpeget at man gerne må tænke stort og implementere småt.
dvs. at arkitekturarbejdet er vigtigt for at sikre at man kan bygge videre på det
"fleksibelt udviklede".

14) Det kan ikke siges for tit at OIO EA skal tilpasses til opgaven/projektet/programmet/myndigheden/situationen, og med lokale anbefalinger omkring værktøjer, governance osv.

Glæder mig til at se næste version i Aarhus.

På gensyn.

Peter Huber
Strand & Donslund A/S
www.s-d.dk
Profilbillede

Gode anbefalinger.

Anders Norgaard

Jeg er generelt enig i anbefalingerne. Der er enorm værdi I at dele mere viden, arbejdsgange, værktøj og løsninger på tværs af det offentlige.

En sådan ensartning gør det jo til gengæld ekstra vigtigt at anbefalingerne hele tiden opdateres og vedligeholdes så de ikke kommer til at fordre unødigt arbejde, eller forældede teknologier.

Jeg er særligt glad for

3. Brug open source-software ved egenudvikling. (Overvej open source, især når du selv udvikler. Udgiv egenudviklet software under open source-licens. Brug Softwarebørsen til at udstille og skaffe ny software.)

Det er så fundamentalt at få på plads. Min oplevelse i IT branchen er at der sker enorme mængder dobbeltarbejde med at udvikle meget ens eller delvist overlappende løsninger. Når softwarebørsen kommer op at køre, burde der være store effektivitetsforbedringer at hente - ikke nødvendigvis at der ligger hele, køreklare løsninger, men mere som "kode der har løst et problem, og som man kan lære af". Men det er nok vigtigt virkelig at presse på med at få alle løsninger på softwarebørsen. Det er så meget lettere for udviklere der er lidt flove over deres kode at finde på undskyldninger for hvorfor "det nok ikke lige egner sig til at blive udgivet som open source".

4. Brug fleksible udviklingsmetoder.

Vigtigt - vandfaldsmodellen er en opskrift på katastrofe.

9. Brug digital signatur og single-sign-on.

Ja, kræv den fælles standard benyttet. Så skulle der også gerne hurtigt dukke moduler op på softwarebørsen som er klar til at benytte og bygge videre på.

12. Stil krav om åbne standarder.

Ja. Åbne standarder er den vigtigste ledetråd når man skal undgå at blive suget ind i proprietære fælder.

15. Del viden og samarbejd på tværs.

Ja. Jeg har store forventninger til softwarebørsen. Søgefunktionen på softwarebørsen bliver meget vigtig. Og anden meta-data ligeså (kontakt-info til udviklere af software på softwarebørsen etc.)

Held og lykke med det
Anders
Hej Anders

Tak for nogle gode pointer! Jeg uddyber lidt omkring 3, 9 og 15:

Ad 3:
I Videnscenter for Software opfordrer vi altid til, at man deler alt hvad man kan / må. Afsenderen skal ikke gå ind i overvejelser omkring om et givet projekt / komponent / kodestump har genbrugspotentiale. Det skal den potentielle genbruger nok selv vurdere.
Din pointe mht. kvaliteten i koden er god.

Ad 9:
Dine bønner er blevet hørt :-)
Mht. single-sign-on kan du på: http://www.softwareborsen.dk/projekter/softwarecenter/brugerstyring finde flere gode ressourcer til den danske SAML2 profil.
Digital signaturkomponenter kan findes på: http://www.openoces.org/
På Softwarebørsen har vi OpenSign komponenten: http://www.softwareborsen.dk/projekter/softwarecenter/digital-signature-applet-opensign

Ad 15:
Ja til videndeling og samarbejde er Softwarebørsen og digitalisér.dk centrale værktøjer.
Vi er meget åbne for fejlrapporteringer, forbedringsønsker m.m. Rapporter vedr. Softwarebørsen sker på: http://www.softwareborsen.dk/projekter/softwarecenter/softwareborsen/issues for digitaliser.dk's vedkommende sker det på: http://www.softwareborsen.dk/projekter/softwarecenter/digitaliser.dk/issues
Kontakt-info til udviklere, som du specifikt nævner, findes som feature. Det er desværre ikke mange der bruger den endnu, hvorfor den kan overses: Virksomheder har mulighed for at oprette sig som leverandør på Softwarebørsen og tilknytte kompetencer til de enkelte projekter. Vi har det ene krav, at man skal sandsynliggøre at man kan bidrage til et projekt på en eller flere måder, for at blive oprettet.
Det er meget vigtigt som vi ser det, at (gen)brugere kan se hvor kan de købe hjælp til f.eks. at installere eller videreudvikle en given komponent.

Hvis du har specifikke ønsker eller forslag til søgefunktionen må du meget gerne indrapportere det på ovennævnte links.

/m
Profilbillede

Kommentarer til de 15 skarpe og forslag til ændringer

René Løhde

Hej,

Her er mine kommentarer til de 15 skarpe.
Først er opgivet det oprindelige skrape forslag, mens mit forslag til ændring eller nyt er anført efterfølgende.


1. Få styr på forretningsgangene
Modellér og dokumentér dine forretningsprocesser med beskrivelsesstandarden BPMN. Når du har styr på arbejdsgangene,har du skabt grundlaget for at optimere din organisation.

1. Beskriv dine forretningsgange
Modellér og dokumentér dine forretningsprocesser med det domæne specikke sprog du og din organisation er mest komfortabel med.
Husk hvis I bruger de værktøjer som I mener bedste beskriver jeres fagområde, så er sandsynligheden stor for at det også nemmere for andre at forstå.

Bemærkninger: Alle taler om DSL'er eller metasprog i øjeblikket, at lægge sig fast på at der skal være et og kun et multipurposed sprog til forretningsprocessor er at gå direkte modstrømmen og vælge en vej som har vist sig ufrugtbar.
Alle domæne eksperter er langt mest produktive hvis de får lov til at bruge deres eget sprog - det gælder for alt fra kommunalesagsbehandlere, pædagoger, finansfolk til IT programmører.


2. Anvend fælles forretningsterminologi
Brug den fællesoffentlige referencemodel, FORM, især i digitaliseringsprojekter, der går på tværs af myndigheder.
En fælles terminologi skaber overblik og sikrer fokus på, hvor man kan genbruge services.

2. Adoptér domæneeksperters forretningsterminologi
Hvis din organisationer laver IT projekter på tværs af myndigheder, så sørg for ledelsesmæssigopbakning i alle de berørte parters organisationer til at engagere domæneeksperterne.
Dette er også en suværen test for at se om andre organisationer mener at projektet giver værdi - hvis de berørte parter mener at projektet er værdi skabende, specielt for dem selv sidder bliver domæne eksperternes tid lettere tilgængelig.

Bemærkninger: FORM er en så high level taksonomi at den ikke i sig selv kan være en "skarp" omdrejningskraft for noget IT projekt, tilgengæld kan den stilles til rådighed som en taksonomi service i sig selv. den er alt for generel til at være operationel i sig selv.


3. Brug open source-software ved egenudvikling
Overvej open source, især når du selv udvikler. Udgiv egenudviklet software under open source-licens. Brug Softwarebørsen til at udstille og skaffe ny software.

3. Udgiv egenudviklet software under open source-licens
Hvis det er muligt bør egenudviklet software stilles til rådighed for andre.
Husk dog at offentlige projekter ofte giver leverandøren en kærkommen anledning til at produktudvikle på leverancen og evt sælge den eller dele af den videre til andre. Derfor er og kan det være en bekostelig affære at sikre sig rettigheder til kildekode og IP for den givne løsning. Gør det kun hvis du har opbakning fra andre organisationer eller projekter.

Bemærkninger: Jeg kender til dato ingen eksempler på at en softwareleverance til et offentligt IT projekt har udnyttet, at det var muligt at lave ændringer på baggrund af krav fra kunden, og efterfølgende lavet en recompile og deploy. Hvorfor så betale ekstra og få de rigtig licenser på plads hvis det aldrig bliver udnyttet at det er OSS.


4. Brug fleksible udviklingsmetoder
Brug agile udviklingsmetoder – og spis elefanten i små bidder. Nedbryd opgaver i mindre komponenter, og test løbende løsningerne i praktisk brug. Det giver bedre løsninger og mindre risiko for at overskride budget og tidsplan.

4. Brug fleksible udviklingsprocesser
Brug udviklingsprocesser, som er lavet til hurtig omstilling og nedbryd opgaver i mindre komponenter. Test løbende komponenterne i praktisk brug.

Bemærkninger: Enig med Jan Heisterbergs indlæg her


5. Dataudveksling skal anvende fælles datastandarder
Brug OIO datastandarder / OIOXML i it-løsninger, der udveksler data med andre myndigheder. Det giver billigere og bedre dataudveksling.

5. Angiv rige metadata for dit systems kommunikation
Ved hver system integration vil der være en række interfaces, api'er etc. For at sikre nem og billig integration er det vigtigt at beskrive så præcist så muligt hvilke data der udveksles og generelle metadata for disse metadata og api'er.

Bemærkninger: Et datastandardsformat for dataudveksling for et domæne kan umiddelbart synes som en god ide, men mine erfaringer siger at alle projekter har specielle krav til udvekling af data som betyder at generaliserede formater, som OIOXML på tværs domæne til dataudvekling ikke er hensigtsmæssige.


6. Offentlige portaler skal hænge sammen
Brug den offentlige integrationsmodel for portaler til integration af webbaserede services. På den måde sikres sammenhæng mellem de store portaler og myndighedernes hjemmesider.

6. Lad offentlige portaler genbruge dit indhold
Orienter dig om hvilket format og med hvilken transport de portaler du ønsker at integrerer til, foretrækker data og præsentation leveret. Som regel kan man nøjes med et format og en kanal og stadig ramme de vægtiste portaler.

Bemærkninger: Den generelle integrationsmodel vil blot byde at dit projekt bliver 1 kilo tungere i krav spec med deraf følgende ekstraregning fra de krav spec udførende konsulenter, leverandøren og de leverandør kontrolerende konsulter. En gylden regel, som jeg har lært af min kollega, Nikolaj La Cour, er at 1 kilo ekstra kravspec koster ca 1 mill pr. leverandør.


7. Webservices skal være nemme at finde og anvende
Dokumentér eksterne, digitale services med et servicestamkort på digitalisér.dk - så der er ét sted at finde de fælles ressourcer.

7. En service skal være nem at finde og anvende
Dokumentér eksterne, digitale services så de er nemme at finde for de mest udbredte søgeteknologier, som dine aftagere benytter. Det kan f.eks være metadata til robotter, tagging, aggregering og publiserings via Web 2.0 teknologier.
Brug den teknologi og de ressourcer, som sikre at informationen om din service, potentielt set når flest mulige aftagere.

Bemærkninger: Servicestamkort er tilsyneladende et begreb som er opfundet til lejligheden - so much for at genbruge egen eller industriel taksonomi aka "skarp #2". Det er ikke lykkedes mig at finde en instans af et servicestamkort, så det er jo nemt at sige - lad være med at bruge det!
Men faktisk selv med stamkort, mener jeg at det er den forkerte tilgang. Hvis der er noget Web 2.0 har lært os så er det at folk er villge til at semantisk berige services og sider hvis de skal gøre det et sted og det har en umiddelbar synlig effekt (f.eks Technorati).
Hvis ikke ITST har fundet på stamkort så kunne det være et sted man skriver endpoint f.eks med Atom/Atom Pub feeds, som aggregeres ind på baggrund af tags. På den måde kan serviceudbyder vedlige holde metadata om services "hjemme" og digitaliser.dk kan aggregere med deres fortrukne søgeteknologi uden af "forstyrre" serviceudbyder.


8. Webservices skal kunne tale sammen
Anvend de anbefalede standarder i implementeringsmodel for forretningsservices ved implementering af web-services. Så er I fremtidssikrede i forhold til samspillet med resten af den offentlige sektor.

8. Interoperabilitet er den vigtigste egenskab ved et IT system
Brug derfor denne populære omskrivning af Postels lov: "Vær konservativ med hensyn til hvad du sender og liberal i hvad du vil modtage!". Lad det simple og etablerede være første valg, men vær altid på udkig efter det, som kan berige din interoperabilitet.

Bemærkninger: Interop sikres bedst ved at: Brug anerkendte, leverandør neutrale profiler og anbefalinger for at få opnå interoperabilitet. Køb ydelser og produkter med størst mulig fokus deres egenskaber til at "leve" i heterogene miljøer.


9. Brug digital signatur og single-sign-on
Følg de fællesoffentlige retningslinier og standarder for implementeringen af digital signatur og single-sign-on. Så kan alle offentlige løsninger tilgås på en ensartet måde, hvilket giver borgere og virksomheder værdi.

9. Brug de autentificering- og autorisationsmekanismer, som giver størst værdi for borgere og virksomheder
Det er vigtigt at alle offentlige løsninger tilgås på en ensartet måde ved autentificering og at der er klart for brugeren hvordan denne får autorisation til en given løsning.

Bemærkninger: Jeg tror ikke på at one-size fits all for alt AuthN til digitale service, men jeg tror på id ID system for det offentlige hvor alle kan spille sammen vha åbne standarder og gennemskuelig arkitektur.


10. Basér indkøb og salg på den fælles infrastruktur for handel
Brug NemHandels standarder, komponenter og infrastruktur, når du implementerer e-handel. På den måde bærer de fælles investeringer en stor del af dine omkostninger.

10. Basér indkøb og salg på et fælles vokabularie for handel
En kandidat er NemHandels standarder, når du implementerer e-handel. På den måde sikre du dig at den semantiske interoperabilitet bliver nemmere for et vigtigt domæne, samt at de potentielle leverandører har stiftet bekendskab med vokabulariet før.

Bemærkninger: Jeg har aldrig forstået hvorfor der skal laves én dedikeret infrastruktur med egen protokol til ehandel i Danmark. Så længe jeg ikke kan finde en begrundelse må mit råd til de offentlige projekt ansvarlige være, at man kan bruge sproget. Hvad med protokol og transport? - vælg din egen, med hensyn til skarp 4


11. Brug fælles sprog på sagsog dokumentområdet
Brug OIO-referencearkitektur for sags- og dokumentområdet til at få styr på ESDH og omegn. Så er løsningen gearet til forretningsmæssige forandringer og nye integrationer.

11. Basér systemer fra sags og dokumentområdet på et fællesoffentlig vokabularie
En kandidat er OIO-referencearkitektur for sags- og dokumentområdet, når du implementerer ESDH. På den måde sikre du dig at den semantiske interoperabilitet bliver nemmere for et vigtigt domæne, samt at de potentielle leverandører har stiftet bekendskab med vokabulariet før.

Bemærkninger: Jeg er sikker på at der i dette land er hoveder, der har visioner for hvordan dette skal gøres. Specielt når man tager FESD særtogene i betragtning: Der er helt sikkert indvolverede, som ved hvordan det skal skrues sammen.


12. Stil krav om åbne standarder
Anskaf løsninger, der bygger på åbne standarder på digitalisér.dk. Åbne standarder fremmer interoperabilitet og konkurrence.


12. Stil krav om høj interoperabilitet og om muligt: proces- og dataportability
Anskaf løsninger, der understøtter en høj grad af interoperabilitet og proces- og dataportabilitet. På den måde er du med til at sikre at du ikke laver et system, som kun kan supporteres, udvikles og drives af en leverandør. På den måde er du med til at sikre større konkurrence på området.

Bemærkninger: Åbne standarder er et af midlerne til at opnå interoperabilitet. Hvorfor ikke bare gøre det "skarpt", så det fremgår hvad det er projektet skal understøtte: Interoperabilitet. Angående "konkurrence", så ved jeg ikke hvilke andre projekter det er at offentlige IT projekter skal konkurrere imod!



13. Skab sikre løsninger
Offentlige myndigheder bør udarbejde en Privacy Impact analyse (PIA), det vil sige en analyse af, hvordan hensynet til privatlivet inddrages, ved nye it-projekter.


13. Skab sikre løsninger
Brug analyse og metoder, som er bredt accepteret til at kortlægge sikkerheds- og privacyproblemstillinger for det aktuelle systemet.

Bemærkninger: Jeg er sikker på at valget at en navngiven analysemetode er en dårlig ide, fordi det implicit antyder et fravalg af andre metoder og analyser, som kan være mindst lige så gode.



14. Få styr på it-arkitekturen
Brug OIO arkitekturmetoden og arkitekturreolen som fælles referenceramme for arbejdet i digitaliseringsprojekter. Så er der styr på dokumentationen og samarbejdet lettes.


14. Få styr på it-arkitekturen
Modellér og dokumentér dine it-arkitektur med det domæne specikke sprog du og din organisation er mest komfortabel med.
Husk hvis I bruger de værktøjer som I mener bedste beskriver jeres arkitektur, så er det også nemmere for andre at forstå.

Bemærkninger: Se skarp 1


15. Del viden og samarbejd på tværs
Opret en gruppe på digitalisér.dk, når du starter et nyt it-projekt, og stil dokumentation til rådighed for andre myndigheder.På den måde er du med til at sprede erfaringer og bedste praksis.

15. Del viden og samarbejd på tværs
For hvert projekt er videndeling en central kilde til succes. Web 2.0 har lært os at online kollaboration indenfor og udenfor firewall'en er en inddiskutabel vinder når det gælder vidensdeling.
Brug de bedste aktuelle trends til intern vidensdeling i projektet og overvej om ikke vidensdeling på projektet også kan tåle dagens lys eksternt. Skalerings mulighederne bliver på den måde næsten uendelige.

Bemærkninger: Jeg kan ikke forstå hvorfor det kun er på digitaliser.dk man kan vidensdele?


mvh René Løhde
Hej René

Et rigtigt interessant og herligt grundigt indlæg, der kommer rundt om alle 15 skarpe. Og indeholder rigtig mange gode bud på alternative eller supplerende formuleringer. Jeg vil ikke kommenteret det hele, men give nogle generelle bemærkninger specielt om de dele der vedrører de overordnede og forretningsmæssige metodeanbefalinger.

Jeg er i og for sig enig i mange af dine betragtninger, som vel næsten kan skrives sammen til at du anbefaler at man tager udgangspunkt i konteksten og vælger sin tilgang ud fra de særlige udfordringer (forretningsmæssige eller teknologiske) og styrker (kompetencer, sprog, tradition osv.) som er i spil i den pågældende kontekst. Kontekst kan i denne sammenhæng svare både til det du kalder domæner og til specifikke projekter.

Jeg er enig i, at man skal tage udgangspunkt i konteksten og ikke blindt anvende specifikke metoder, standarder osv. Og slet ikke blindt, ukritisk og slavisk.

Men jeg synes at du misser en meget vigtig pointe i flere af anbefalingerne: Den tværoffentlige OIO-komités udgangspunkt for disse anbefalinger er, at der er behov for at kunne samarbejde, dele viden, genbruge data og etablere fælles løsninger på tværs af forretningsmæssige domæner som fx sundhed, velfærd og penge.

Der er også steder hvor du misser pointen i formålet med de fælles metoderammer, standarder og sprog, som vi peger på. Anbefalinger af fx BPMN (#1), FORM (#2), OIO EA (#14), og referencearkitektur for sags- og dokumentområdet (#11) er netop beregnet på at facilitere analyse, strategiudvikling, koordinering og samarbejde på et ret højt niveau. Det udelukker på ingen måde en mere operationel, domæne-/opgavespecifik udbygning.

Mht. BPMN synes jeg - uanset BPMN's kvaliteter - at det er en vigtig pointe for det tværoffentlige samarbejde og fremdrift i modernisering og digitalisering, at KL har et storstilet arbejde i gang med at beskrive de kommunale arbejdsprocesser inden for stort set alle de områder, hvor kommunerne har opgaver (altså på tværs af domæner). Og at det arbejde sker netop ved hjælp af BPMN. Men naturligvis med stort fokus på at anvende de begreber og termer, som anvendes i de enkelte domæner qua lovgivning eller administrativ praksis.

På samme måde kan man sige at FORM har en særlig og selvstændig kvalitet i og med at den bliver mappet til både KL's journalplan og til Finansloven, som jo er sprog, der anvendes på tværs af domæner / myndigheder. Og at den mappes til services på fx borger.dk, der også rummer indhold på tværs af domæner/myndigheder. Det er værdifulde egenskaber, men gør selvfølgelig ikke FORM til en silverbullet, der kan løse alle problemer for et forretningsprog på mere operationelt niveau. Derfor er jeg helt ening i din supplerende pointe, men IKKE i din alternative formulering.

Og så lige til sidst ad skarp #15 om at dele viden via digitalisér.dk. det kan selvfølgelig ske via mange andre kanaler – det er både tillad at sende e-post, mødes over en øl på en café, gå til netværksmøder, blogge osv. Men digitalisér.dk er et nyt tilbud, som sætter fokus på at understøtte det danske fællesskab / domæne for digital forvaltning - og lidt til, da private er velkomne til at deltage og dele viden og ressourcer.

Med venlig hilsen

Michael Bang Kjeldgaard
Hej Michael,

Tak for svaret! Jeg har lige et par kommentarer.

Du har muligvis ret i at jeg har misforstået og at mine hensyn til "Den tværoffentlige OIO-komités udgangspunkt for disse anbefalinger er, at der er behov for at kunne samarbejde, dele viden, genbruge data og etablere fælles løsninger på tværs af forretningsmæssige domæner" ikke er tilstede.
Det skyldes nok at det kan jeg ikke læse ud af de 15 skarpe, men det er en implicit viden du bringer til debatten. Faktsik forholder jeg mig meget konkret til de 15 skarpe som "praktisk rettesnor i hverdagen" for målgruppen: "offentlig it-chef, projektleder eller professionel der arbejder med digitalisering".

For mig er en praktisk rettesnor - godos, med understregning af og tryk på "praktisk".


Hvis man forholder dette til BPMN, FORM, OIO-EA og ESDH, som du nævner så beskriver du dette, som "at facilitere analyse, strategiudvikling, koordinering og samarbejde på et ret højt niveau." - Med undtagelse af ESDH, så er jeg enig i at det er på et ret HØJT niveau. Jeg tror at et "ret højt niveau", giver disse 15 råd til it-chefer, projektledere etc. en alt for generel drejning, som ikke gør tingene praktiske. Tvætrtimod er jeg bange for at de stiller flere spørgsmål, som kan komplicere projekter yderligere.
Dermed ikke sagt at de ikke hverisær har sin berettigelse, for det tror jeg de har, men ikke som en generel praktisk vejledning for offentlige it-projekter.


Mht BPMN, FORM og andre taksonomierne og diverse DSL'er så tillad mig følgende citat som jeg fik hugget fra Torben Mogensen i går (http://www.version2.dk/artikel/9403-dsler-er-ikke-for-almindelige-mennesker):

"Et DSL bør ... lægge sig op af de udtryksformer, som i forvejen bruges af domæneeksperterne til kommunikation indbyrdes, uanset om disse udtryksformer er grafiske eller symbolske. Der skal forenkles og disambigueres, men det kan for det meste gøres uden at miste forbindelsen til domæneeksperternes erfaring."

For mig betyder at det er svært at lave generel vejledning om hvilke processprog, forretningsmodelleringværktøjer og det er nok der jeg får lidt sure opstød af at se navngivne standarder i de 15 skarpe. Samtidigt er jeg dog ikke blind for at specielt på dette område, er det svært at være "praktisk".

God jul

-René



Profilbillede

Skarp nr. 14: Få styr på it arkitekturen med metodik - nu anbefalet af Rigsrevisionen!

Michael Bang Kjeldgaard

Skarp nr 14. får anbefaling med på vejen fra Rigsrevisionen:

"Rigsrevisionen kan henvise til IT- og Telestyrelsens "OIO Enterprise Arkitektur" fra 2007, som kan anvendes til gennemførelse af it-projekter med henblik på en styrkelse af fremtidige beslutningsgrundlag." (s 11 i rapporten Beretning til Statsrevisorerne om styring af statslige digitaliseringsprojekter - læs den på http://www.rigsrevisionen.dk/media(772,1030)/2-2008.pdf.)

Læs om OIO EA metoden her: http://ea.oio.dk
Har du erfaringer eller holdinger du vil dele om brug af OIO EA?
[slettet indlaeg]
Profilbillede

Join debatten !

Benny Rysz

Forsidehenvisning på ITST.DK
Enhver som har fulgt med, ikke mindst i Rigsrevisionens seneste rapport, må hilse initiativer velkomne. God it er og bliver i stadig højere grad en gevinst for brugerne og systemejerne.

Der er (sikkert) mange gode forslag blandt de "15 skarpe til digitalisering af Danmark" og enhver vil synes bedst om sit specielle krav eller kæphest, men jeg vil fokusere på nr. 4 - som desværre har fået titlen: "Brug fleksible udviklingsmetoder".

Muligvis menes der virkelig "udviklingsmetoder", men i min ordbog handler udviklingsmetoder mest om "kodning" og mindre om den samlede udviklingsproces.

I min ordbog er en udviklingsproces den overordnede, alt omfattende proces fra ide eller behov til succesfuld anvendelse. Udviklingsmetoden, som nævnt ovenfor, er en del af processen men ikke hele processen. Måske en strid om ord, men aligevel.

Og nu til det helt centrale - uanset om det begraves i punkt 4 ELLER ophøjes til et hovedpunkt: det er fuldstændigt centralt som skrevet står: "spis elefanten i små bidder" ELLER med et mere teknisk udtryk: anvend en iterativ udviklingsproces.

Og hvad er ITERATIV UDVIKLINGSPROCES ? Det er en proces som kapitaliserer på især TO forhold: vi kan ikke vide alt fra starten (dvs. store, endelige kravsspecifikationer har spillet fallit), OG brugerne bliver inspireret under vejs (dvs. der vil uundgåeligt komme ændringer (altså: "kan man ikke istedet" eller "det var bedre hvis")).

Med andre ord: de moderne systemer er næsten alle udviklet til mange brugere, måske endog borgere og ikke sagsbehandlere (som kan uddannes). Udviklingsprocessen skal følgelig udvikles som en serie prototyper, den næste endnu bedre end den foregående. Efter 3 eller 4 iterationer vil målet sikkert være i sigte (hvis altså 1) de rigtige brugere prøver systemet, 2) de bedste og nødvendige ændringer indkorporeres i næste prototype).
Er det let at estimere omkostningen ? Måske ikke, men det er ikke en undskyldning for istedet at levere noget brugerne ikke kan / vil anvende.

SÅ: Spis elefanten i små bidder. Test løbende prototyperne i praktisk brug.

Og selvfølgelig sigt også efter de andre mål, ikke mindst nr.1, 2, 5 og 11.

YES, go do it !
Hej Jan

Tak for inputtet!

Jeg er i øvrigt helt enig, det bør bredes ud og ikke kun dække udviklingsmetoder, men hele processen, som også er sigtet med anbefalingen. Når vi anbefaler agile/iterative udviklingsmetoder og processer er det netop fordi, vi på egen krop, har set at det virker!

Vh

Christian Lanng
It & Telestyrelsen