Hvad mener du om de 15 skarpe?

15 forretningsgange er umiddelbart 5 for meget. Keep them simple, og lad være med at overgøre alt for mange regler. 

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

[slettet indlaeg]

[slettet indlaeg]

[slettet indlaeg]

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

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:-)

 

 

[slettet indlaeg]

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,

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

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]

Forsidehenvisning på ITST.DK