Embed Size (px)
DESCRIPTION
Citation preview
Åpen programvare — raskere vei
til målet, eller sidespor?Jan Christiansen, IKT-direktør, NSB AS
IKT i NSB
• IKT benyttes i utstrakt grad for å støtte forretningsprosessene i hele konsernet
• Mange av systemene er virksomhetskritiske
• Bortfall av systemtjenestene vil svært raskt gi negative effekter i form av inntektssvikt, nedgang i
omdømme og problemer med trafikkavviklingen
• Mange av støtteprosessene er automatisert og krever systemstøtte (Lønn, Personal, regnskap,
faktura o.s.v.)
• Mange (og komplekse) grensesnitt
• Streng standardisering / styring av sluttbrukertilgang
• Full kontroll over desktop
• I utgangspunktet minimale rettigheter – utvides ut fra ”Need to see”
NSB har klare prioriteringer i sin IKT-strategi
Kundeprosesser
NSB-prosesser
Utvikle
togtilbud
Markedsføre
og selge
togtilbud
Transportere
kunde
Planlegge
reise
Velge
reisemåte
Bestille
og betale
Gjennomføre
reisen
Støtte-
prosesser
Reiseinformasjon
Plansystemer
Salgssystemer /
kanaler
Kampanje /
informasjon
Informasjon
under reisen
Støttesystemer
Informasjon til egne ansatte
1. IKT-støtte til
prosesser som
berører kundene
direkte
2. IKT-støtte som gjør
ansatte i
hovedprosessene i
stand til å gjøre en
bedre og mer
effektiv jobb
3. IKT i
støtteprosessene
for å gjøre disse så
enkle og
kostnadseffektive
som mulig
Hvorfor har vi valgt å bruke åpen programvare?
• Kvalitet
– Sammenligning gjort av oss (og andre) viser at ”modne” og profesjonelle åpne programvareprodukter har en langt høyere kvalitet enn tilsvarende kommersielle produkter
• Tilgang på kompetanse
– Kompetanse på og erfaring med de ledende åpne produktene er lett å få tak i, og er ikke begrenset til spesielle miljøer
– Dokumentasjon, eksempler og implementeringer som en kan bygge videre på er lett tilgjengelig
• Utviklingstakt og fleksibilitet
– På grunn av den store utviklerbasen tar åpne produkter raskere opp trender og nye måter å gjøre tingene på
– Av samme grunn – og fordi produktene brukes på så mange måter – vil de stort sett være langt mer fleksible og tilpasningsvennlige enn kommersielle produkter
• Forholdet til standarder
– Åpne produkter er stor sett langt mer standardiserte enn kommersielle – og har færre særegenheter
– Det er typisk at referanseinstallasjoner for de større standardene er åpne
• Pris
– Anskaffelsesprisen er ofte lavere
– Levetidskostnadene har vist seg å være lavere enn for kommersielle produkter – selv om en må ta kostnadene ved å holde rede på versjoner, og må betale hvis en ønsker ”kommersiell” støtte
Hvor bruker vi åpen programvare?
• Som deler av større løsninger– Portal for intranett (LifeRay)
– Søk (Lucene, Solr)
– Grafikk / presentasjon (JFreeChart)
– Caching
• I forbindelse med utvikling– Eclipse, NetBeans
– JUNIT
• Som komponenter i egenutviklede løsninger– Rammeverk (Spring)
– Persistens (Hibernate)
– Brukerinteraksjon (PHP, Apache Wicket)
• Som makrokomponenter i arkitekturen– Enterprise Service Bus (Mule, JBoss ESB,
Open ESB)
• Som komponenter i infrastrukturen– Sikkerhet / Identitet (OpenSSO)
– Servlet-container (Tomcat)
– Applikasjonsserver (JBoss, GlassFish)
– Web-server (Apache)
Hva med desktoppen?
• Vi har – i likhet med de fleste andre større norske aktører – valgt å holde desktop’en på en ”lukket” plattform
(Microsoft).
• Det er mange grunner til dette – de fleste er knyttet til risiko ved overgangen, ikke selve produktspekteret
– Det er gjort en svært stor investering i å bygge opp kompetanse på Office-produktene
– Det finnes en svært stor eksisterende dokumentbase som måtte konverteres – eller i alle fall gjennomgås – ved et
eventuelt bytte
– For denne typen produkter er vi helt avhengige av tilgang på dokumentasjon, opplæring og kompetanse
– Det har vokst opp en stor industri med tilleggsprogramvare som er tilpasset Office
• Det er heller ikke helt sikkert at det ville lønne seg økonomisk
– Kostnadene knyttet til bruk av åpen programvare for sluttbrukere er vanskelig å estimere på forhånd. Og det er tøff
konkurranse med gode Enterprise-avtaler…
• Derfor: Vi har valgt å holde desktop’en utenfor inntil videre
– Men Microsoft: Dere må fortsette å levere!
Utfordringer for åpen programvare
• På samme måten som for annen ”Intellectual Property” må det etableres gode og
velfungerende Økosystemer for åpen programvare
– De som yter en innsats må få noe tilbake – ”cred” på gutterommet holder ikke når det er snakk
om store, komplekse og virksomhetskritiske systemer
– Det må eksistere pålitelige og tilgjengelige kommersielle støttesystemer som kan gi garantier for
bistand
– Det må ligge til rette for god dialog mellom ”kunder/brukere” og ”utviklere/leverandører”
• Det er også viktig at produktene ”lever”, blir utviklet og oppgradert i henhold til nye
moderne standarder og forventninger. Dette forutsetter også en åpen dialog mellom
brukere og utviklere som ikke kommer av seg selv.
Finnes det en god kombinasjonsmodell?
• Noen aktører har forsøkt å lansere en kombinasjonsmodell, der de går aktivt inn og bidrar til utvikling av programvare i miljøer som utvikler åpen programvare. Dette gjør de gjennom å
– Stille til rådighet ”lukket programvare” for videreutvikling i åpne miljøer
– Stille med betalte, egne ressurser som aktive bidragsytere i utviklingsprosessen
– Stille til rådighet infrastruktur for utviklingsarbeidet – verktøy, Wiki’er, fasilitatorer og kommentatorer o.s.v.
– Utarbeide profesjonell dokumentasjon for produktene
– Bidra med markedsføring av produktene i sine kanaler
– Levere ”Enterprise”-versjoner av programvare. Dette er stabile versjoner av programvaren, ofte pakket sammen i ”bundles” på en måte som skal gjøre det enklere å håndtere for sluttbruker. Disse versjonene skal betales, både for anskaffelse og for vedlikehold – men prisene er ofte betydelig lavere enn tilsvarende ”helkommersiell” programvare.
Er dette vellykket?
• Noen erfaringer med delvis åpne produkter fra Sun Microsystems:
– Supportfunksjonen er for dårlig, og det er mye lettere å finne detaljert informasjon om produktene i de
ulike åpne fora. Det betyr at en helt klart må vurdere nytten av å ha en vedlikeholdsavtale
– Dokumentasjonen er svært mye bedre enn det en vanligvis finner for åpen programvare, men dette
gjelder i første rekke de mer ”administrative” aspektene – installasjon, konfigurering, drift o.s.v. For
detaljert informasjon knyttet til utviklingsarbeid er fremdeles de ”tradisjonelle” åpne fora bedre.
– Hvis produktene fortsetter å utvikle seg i en ”åpen”, gratis versjon og en ”delvis lukket” enterprise-
versjon må leverandøren gi mer for at vi skal ta i bruk denne.
• Det at store deler av programvaren vi har benyttet er åpen gjør at vi får større valgfrihet etter
oppkjøp
– De åpne delene av produktene kan benyttes videre, men vi må finne gode alliansepartnere
– De lukkede delene av produktene må erstattes med åpne – og det er dessverre noen slike deler i det vi
benytter
Går NSB videre med åpen programvare?
• Åpen programvare er – og vil forbli – en viktig del av vår applikasjonsstrategi
– Vi vil fortsette å benytte modne åpne komponenter i utviklingsprosjekter
– Vi vil evaluere åpne programvareprodukter på linje med kommersielle produkter i
anskaffelsesprosesser. Vi vil ha som en målsetning å ha med åpen programvare i evalueringen
hvis slike finnes.
• Vi vil fortsette å evaluere modellen med ”managed” åpen programvare og se om denne
gir en bedre kvalitet og lønnsomhet enn den ”tradisjonelle” modellen
– Skal vi inngå forvaltningsavtaler med leverandører, eller benytte de ”åpne” versjonene og bygge
opp egen kompetanse / kjøpe fra konsulenter som vi har rammeavtale med?
Hva kan / bør gjøres for å få fart i åpen
programvare i offentlig sfære?
• Fortsette å ”evangelisere”
– Vis til (eventuelle) vellykkede historier
– Samle interessenter til erfaringsutveksling
• Bidra med ressurser til utvikling og support
– Målrettede bevilgninger til utviklingsarbeid som det offentlige Norge har behov for
– Mye sterkere samarbeid mellom statseide institusjoner og universitets/høyskolemiljøer
– Oppbygning av sentral kompetanse og støttefunksjoner i samarbeid med profesjonelle aktører
• Tilrettelegge anskaffelsesreglene for også å kunne evaluere åpen programvare
