bloghoved rene løhde

15 nye skarpe

It og Telestyrelsen er har travlt med at få de IT interesserede i Danmark med på at lave e-Gov med web 2.0 metoder. Seneste er det blevet til to debatoplæg, som begge har været omtalt på V2.dk. Okay, så lad os få en debat!

På trods af Helge Sanders begejstring for OSS, så savner pjecen i min optik berettigelse og jeg har derfor kastet min debatenergi efter de "15 skarpe", som rigsrevisionen tilsyneladende godt kan lide. Samtidigt har jeg selv kigget nærmere på flere offentlige IT projekter og mener således at have et (spinkelt) oplyst grundlag. Bl.a. fordi jeg efterhånden har været både policy making på den ene side af bordet og udførende på den anden side. 

[Note! 3 sektioner indsat 17.12.2008]
De 15 skarpe bliver præsenteret i IT og Telestyrelsens materiale med følgende tekst:

"Som offentlig it-chef, projektleder eller professionel der arbejder med digitalisering, skal du træffe mange valg i en hektisk hverdag.
Derfor har IT- og Telestyrelsen samlet 15 klare best practice-anbefalinger, der kan bruges som en praktisk rettesnor i hverdagen. Vi håber, at vi med disse anbefalinger kan være med til at fremme god it-arkitektur i det offentlige.
Anbefalingerne er rettet mod de udfordringer, som det offentlige står med lige nu, og bygger på aktuelle erfaringer fra hele den offentlige sektor."

Det er i samme kontekst som jeg foreslår nedenstående ændringer.

Her er mine kommentarer til de 15 skarpe, som jeg også har posted på digitaliser.dk.

I kursiv er den oprindelige skrape opstillet, mens mit forslag til ændring eller nyt og bemærkninger 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.

  2. 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 bestemme sig for kun et sprog til forretningsprocessor er at gå direkte mod strømmen og vælge en vej, som allerede 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. 

  1. 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.   

  1. 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.

  2. 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.

  1. 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 på digitaliser.dk.

  1. 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.

  2. 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.

  1. 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.

  2. Lad offentlige portaler genbruge dit indhold
    Orienter dig om hvilket format og med hvilken transport de portaler du ønsker at integrere 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, er at 1 kilo ekstra kravspec koster ca 1 mill pr. leverandør.

  1. 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.

  2. 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/aggregator teknologi uden af "forstyrre" serviceudbyder.  

  1. 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.

  2. 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.

  1. 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.

  2. 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. 

  1. 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.

  2. Basér indkøb og salg på et fælles vokabularium 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 projektansvarlige være, at man kan bruger sproget. Hvad med protokol og transport? - vælg din egen, med hensyn til interoperabillitet. 

  1. 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.

  2. Basér systemer fra sags og dokumentområdet på et fællesoffentlig vokabularium
    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.

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

  2. 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!

  1. 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.

  2. 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.

  1. 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.

  2. 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å den.

Bemærkninger: Se skarp 1

  1. 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.

  2. 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. Skaleringsmulighederne bliver på den måde næsten uendelige. 

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

That's it, men jeg er naturligvis åben for dialog ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lars Hansen

Det er svært at se dine 15 skarp som andet end at du har et helt andet udgangspunkt end forfatterne bag de oprindelige skarpe (Rigsrevisionen). Når udgangspunktet er så forskelligt, så synes jeg at det vil være lidt omsonst at begynde at diskutere dine rettelser til de enkelte punkter.

Som jeg ser det, så er en af de centrale emner for de (oprindelige) 15 skarpe, at der søges en højere grad af genbrug og standardisering i det offentlige (herunder også af metoder og artefakter).

I dine 15 skarpe så sker der en gevaldig udvanding af dette ideal. Det kan man så være for eller imod (og det er fair at diskutere om rigsrevisionens udspil er for dogmatisk).

Men som sagt, så synes jeg at de bagvedliggende holdningsforskelle er så store, at det giver meget lidt mening at afveje dine skarpe mod de oprindelige. I vil simpelthen to forskellige ting.

P.S. Der er vist kludder med de to links til v2.dk debatindlæggene

  • 0
  • 0
#3 René Løhde

Lars,

Tak for kommentarer, de gav anledning til selvransagelse og derfor har jeg ændret posten så den manglende kontekst nu er tilføjet. Jeg har kopieret indledningsteksten fra den oprindelige pjece.

Jeg giver forslag til ændringer af de 15 skarpe, som jeg mener er bedre, som "rettesnor" til den "offentlige it-chef, projektleder eller professionelle der arbejder med digitalisering".

Mht udvanding - kan du så ikke give mig et konkret eksempel fra de 15, så skal jeg forsøge at begunde og forsvare mine ændringer.

-René

PS. Jeg har ingen anelse om hvad der sker med de links.

  • 0
  • 0
Log ind eller Opret konto for at kommentere