Kender du Danmarks bedste it-arbejdsplads?
Vær med til at udpege den bedste blandt nogle af Danmarks største it-virksomheder og it-arbejdspladser og deltag i konkurrencen om et rejsegavekort á 5.000 kr. og fem gavekort à 500 kr.
Energistyrelsen
Sigma Designs Denmark
Danfoss A/S
Novo Nordisk A/S
Afstemning
NemID har nu været i brug i to måneder. Har du fået en NemID?
Cybercity dropper BEA og går open source
Konkret vil Cybercity ikke oplyse, hvilke besparelser de har opnået ved at droppe BEA som integrationsplatform til fordel for open source-produktet JBoss, men fordelene taler de gerne om.
Efter i flere år at have brugt BEA som middleware i systemintegrationen, har Cybercity, der er internetdelen af Sonofon, der igen er ejet af norske Telenor, nu besluttet at droppe BEA og i stedet kastet sig over open source-alternativet JBoss fra Red Hat.
»Platformen giver os en standardiseret måde at kode integration på. Med produktet får man værktøjer som køer, overvågning og clustering, en række integrationsgateways samt en ensartet deployment (udrulning, red) model. Herudover kommer platformen med et udviklingsværktøj, samt en struktur for hvordan services bør udvikles og idriftsættes. Vi kan dermed anvende en teknologi og en platform og dermed også et fælles sæt standarder og procedurer til den integration, vi hidtil har udviklet i eksempelvis Perl, PHP, Bash og TCL,« siger chefarkitekt i Cybercity Thorbjørn Blixen-Finecke til Version2.dk.
Han peger desuden på, at en ensartet udrulningsmodel, og mulighed for ensartet overvågning gerne skulle gøre Cybercitys ret komplekse integrationsstruktur lettere at styre rent driftsmæssigt.
»Det faktum, at services på platformen automatisk skalerer med clustering, gør, at det bliver væsentligt nemmere at skrive fremtidssikrede løsninger, fordi vi ved større belastning blot kan tilføje nye clusternoder frem for at skulle gentænke hele it-løsninger,« siger Thorbjørn Blixen-Finecke.
JBoss er open source og prissættes med en serviceaftale betydeligt under BEA Weblogic, og netop platformens pris betyder, at Cybercity kan anvende platformen flere steder i deres netværk, uden det giver en voldsom stigning i licens- og support-omkostninger. Hertil kommer, at JBoss-platformen kan køre på mange forskellige styresystemer, typer af hardware og forskellige databaser, hvilket gør det nemmere for Cybercity at integrere platformen i selskabets eksisterende setup.
»Sidst men ikke mindst betyder open source-konceptet, at vi kan bidrage til den retning, platformen udvikler sig i. Dette har blandt andet gjort, at platformens FTP integrationsgateways nu understøtter SFTP og FTPS med brug af public/private key authentificering og certifikater. Fordelen er, at leverandøren af platformen overtager ansvaret for eksempelvis QA og videreudvikling af den kode, der faktisk føres tilbage i produktet,« siger Thorbjørn Blixen-Finecke.
En BEA Weblogic licens kan snildt koste op mod 100.000 kroner per CPU, men alligevel vil Thorbjørn Blixen-Finecke ikke komme ind på de konkrete besparelser, som Cybercity har opnået ved skiftet,
»Man kan danne sig et billede af besparelsen ved at se på de listepriser andre leverandører oplyser. Selv med en stor reduktion af prisen, vil en anden leverandørs løsning være væsentligt dyrere per CPU, end den JBoss SOA Platform vi nu har valgt,« siger han.
»Platformen giver os en standardiseret måde at kode integration på. Med produktet får man værktøjer som køer, overvågning og clustering, en række integrationsgateways samt en ensartet deployment (udrulning, red) model. Herudover kommer platformen med et udviklingsværktøj, samt en struktur for hvordan services bør udvikles og idriftsættes. Vi kan dermed anvende en teknologi og en platform og dermed også et fælles sæt standarder og procedurer til den integration, vi hidtil har udviklet i eksempelvis Perl, PHP, Bash og TCL,« siger chefarkitekt i Cybercity Thorbjørn Blixen-Finecke til Version2.dk.
Han peger desuden på, at en ensartet udrulningsmodel, og mulighed for ensartet overvågning gerne skulle gøre Cybercitys ret komplekse integrationsstruktur lettere at styre rent driftsmæssigt.
»Det faktum, at services på platformen automatisk skalerer med clustering, gør, at det bliver væsentligt nemmere at skrive fremtidssikrede løsninger, fordi vi ved større belastning blot kan tilføje nye clusternoder frem for at skulle gentænke hele it-løsninger,« siger Thorbjørn Blixen-Finecke.
JBoss er open source og prissættes med en serviceaftale betydeligt under BEA Weblogic, og netop platformens pris betyder, at Cybercity kan anvende platformen flere steder i deres netværk, uden det giver en voldsom stigning i licens- og support-omkostninger. Hertil kommer, at JBoss-platformen kan køre på mange forskellige styresystemer, typer af hardware og forskellige databaser, hvilket gør det nemmere for Cybercity at integrere platformen i selskabets eksisterende setup.
»Sidst men ikke mindst betyder open source-konceptet, at vi kan bidrage til den retning, platformen udvikler sig i. Dette har blandt andet gjort, at platformens FTP integrationsgateways nu understøtter SFTP og FTPS med brug af public/private key authentificering og certifikater. Fordelen er, at leverandøren af platformen overtager ansvaret for eksempelvis QA og videreudvikling af den kode, der faktisk føres tilbage i produktet,« siger Thorbjørn Blixen-Finecke.
En BEA Weblogic licens kan snildt koste op mod 100.000 kroner per CPU, men alligevel vil Thorbjørn Blixen-Finecke ikke komme ind på de konkrete besparelser, som Cybercity har opnået ved skiftet,
»Man kan danne sig et billede af besparelsen ved at se på de listepriser andre leverandører oplyser. Selv med en stor reduktion af prisen, vil en anden leverandørs løsning være væsentligt dyrere per CPU, end den JBoss SOA Platform vi nu har valgt,« siger han.
Bliv klogere på artiklens emner i Version2's gruppeunivers:
Eclipse.dk
Enterprise Architecture
Mainframe
Sidsel,
Jeg har også leget med Glassfish et års tid, og ville ikke have problemer med at kalde det produktionsmodent. At det så samtidig er ekstremt let at gå til - med version 2 også i et clustered setup - er bare et ekstra plus.
Såæh, har ærligt talt svært ved at se, at Java Application Servers efterhånden skulle være andet end en almindelighed på linie med vand i hanen og jord i haven. I hvert fald ikke noget, man burde erlægge 100k+ per CPU for ...
Jeg har også leget med Glassfish et års tid, og ville ikke have problemer med at kalde det produktionsmodent. At det så samtidig er ekstremt let at gå til - med version 2 også i et clustered setup - er bare et ekstra plus.
Såæh, har ærligt talt svært ved at se, at Java Application Servers efterhånden skulle være andet end en almindelighed på linie med vand i hanen og jord i haven. I hvert fald ikke noget, man burde erlægge 100k+ per CPU for ...
[qoute]I hvert fald ikke noget, man burde erlægge 100k+ per CPU for ...[/qoute]
Der er jo så noget der hedder værktøjsunderstøttelse og support som BEA har der gør det betydeligt nemmere at arbejde med end de tilsvarende OpenSource værktøjer. Spørgsmålet er så hvorvidt det er de penge værd, det vil jeg overlade til kunden at beslutte.
Der er jo så noget der hedder værktøjsunderstøttelse og support som BEA har der gør det betydeligt nemmere at arbejde med end de tilsvarende OpenSource værktøjer. Spørgsmålet er så hvorvidt det er de penge værd, det vil jeg overlade til kunden at beslutte.
Der er jo så noget der hedder værktøjsunderstøttelse og support som BEA har der gør det betydeligt nemmere at arbejde med end de tilsvarende OpenSource værktøjer.
Som f.eks.? :)
Nu står der i artiklen at de har har lagt vægt på det udviklingsværktøj de får med JBoss (uden at jeg ved hvilket det er, men sikkert en rebranded Eclipse, ligesom BEA), og også at de har købt en support kontrakt - hvordan adskiller sådan en sig væsentligt fra en support kontrakt hos BEA?
Mvh,
Søren
IH TSITY BITYS, ta' med mig til BEA,
IH TSITY BITYS, ta' med mig til BEA.
Vejen er lavet af vores comtroller,
tag skoene af for ledelsen tåler
kun dem der vil slikke deres tæer,
kys og skrab for dem her!
Lyt til kapitalfonten, der skråler,
at vi er inviteret til lamer bal.
Så IH TSITY BITYS, ta' med mig til BEA.
Den flyvende boble gik ned klokken otte,
Men Jim Whitehurst har ringet
og og sagt vi ka nå det...
Vi har open source programel med
I vores businessmodel ved
Frederikskaj hvor papegøjen blev skudt
uden at nogen sælgere så det
Vi bruger JBOSS og PHP i Sonofons hal
Så IH TSITY BITYS, ta' med mig til java bal.
;-) Thomas
IH TSITY BITYS, ta' med mig til BEA.
Vejen er lavet af vores comtroller,
tag skoene af for ledelsen tåler
kun dem der vil slikke deres tæer,
kys og skrab for dem her!
Lyt til kapitalfonten, der skråler,
at vi er inviteret til lamer bal.
Så IH TSITY BITYS, ta' med mig til BEA.
Den flyvende boble gik ned klokken otte,
Men Jim Whitehurst har ringet
og og sagt vi ka nå det...
Vi har open source programel med
I vores businessmodel ved
Frederikskaj hvor papegøjen blev skudt
uden at nogen sælgere så det
Vi bruger JBOSS og PHP i Sonofons hal
Så IH TSITY BITYS, ta' med mig til java bal.
;-) Thomas
Iflg. Gartner er der ikke økonomiske fordele ved at anvende OS når alt tages i betragtning, f.eks. drift/monitorering, fejlhåndtering, udviklingsproduktivitet, connectivity og support.
Når man læser artiklen skinner det da også igennem at Cybercitys beslutning er strategisk funderet.
Det vigtigste omkring beslutningen af integrationsplatform er formentlig at man tror på den og satser 100% på at den skal udnyttes til det den er god til - overalt i virksomheden.
Dernæst at man bygger et kompetence center for integration, der får lov til at lave integration på den rigtige måde, uanset at der sidder stærke kræfter rundt omkring i organisationen, der synes at integration skal ske på en anden måde eller på en anden platform.
Prisen for dette kompetencecenter overgår formentlig licensprisen med flere længder. Med andre ord synes jeg licensprisen får et helt forkert fokus og opmærksomhed i denne artikel.
Når man læser artiklen skinner det da også igennem at Cybercitys beslutning er strategisk funderet.
Det vigtigste omkring beslutningen af integrationsplatform er formentlig at man tror på den og satser 100% på at den skal udnyttes til det den er god til - overalt i virksomheden.
Dernæst at man bygger et kompetence center for integration, der får lov til at lave integration på den rigtige måde, uanset at der sidder stærke kræfter rundt omkring i organisationen, der synes at integration skal ske på en anden måde eller på en anden platform.
Prisen for dette kompetencecenter overgår formentlig licensprisen med flere længder. Med andre ord synes jeg licensprisen får et helt forkert fokus og opmærksomhed i denne artikel.
Iflg. Gartner er der ikke økonomiske fordele ved at anvende OS
Gartner har endnu ikke haft ret i NOGEN af de forudsigelser, der ligger mere end to år ude i fremtiden. Gartner er næsten så irrelevant, som det er muligt at være.
... Med andre ord synes jeg licensprisen får et helt forkert fokus og opmærksomhed i denne artikel.
Sådan læste jeg heller ikke artiklen, men du har ret i, at der tit fokuseres for meget på licensbesparelsen, når talen falder på opensource. Det har klart en betydning for private, men for virksomheder er det andre fordele, der er mere væsentlige:
1) Licensadministration er rigtig, rigtig bøvlet! Alle de systemer med licensserver, som jeg har set, koster bare meget tid. Tid, som man kunne bruge på at tjene penge i stedet for.
2) Når man har kildeteksterne kan man altid få lavet de tilpasninger, der er nødvendige. Med et firma som Cybercity/Sonofon/Telenor vil der altid være behov for tilpasninger. Har man ikke in-house viden, så kan man købe det, og vel og mærke fra dem, der giver mest valuta.
3) Med opensource kommer man ikke ud for forretningsmæssige benspænd som f.eks. at der er indsat en begrænsning i antallet af brugere eller antallet af poster i regnskabet. Opensource software er ikke ude i de der spil, der går ud på at malke aftagerene mest muligt.
Selvfølgelig er der ikke noget, der hedder en gratis frokost, men typisk betaler man for en konkret ydelse (forbedring, support, modul, undervisning, etc.), hvor prisen dannes i et åbent marked. Hvis leverandøren sidder med nøglen til systemet, vil prisen typisk afspejle aftagerens behov/smertegrænse og ikke den reelle omkostning, der ligger i det.
Som privatperson kan opensource være meget sjovt og underholdende, men for en virksomhed, der skal gardere sig mod at blive malet ind i et hjørne, er opensource en livsforsikring for, at man kan tage sin løsning med sig og gå, hvis leverandøren ikke lever op til ens forventninger. Det er meget mere værd end en licenspris (der jo stadig kommer oven i hatten).
Thomas
Gartner har endnu ikke haft ret i NOGEN af de forudsigelser, der ligger mere end to år ude i fremtiden. Gartner er næsten så irrelevant, som det er muligt at være.
Jeg kan næsten regne ud at dit næste råd må være helt og holdent at lytte til Thomas Ammitzbøll-bach hvis man vil være klogere :-)
Nu laver Gartner ikke kun forudsigelser men også analyser blandt deres mange kunder. Så når de mener at open source ikke er billigere end kommerciel software er der nærmere tale om en konstatering.
Der er så mange nuancer i denne snak. Når du f.eks snakker om livsforsikring mod vendor lock-in så er der netop mange virksomheder der er glade for deres vendor lock-in. Fordi det modsatte af vendor lock-in er vendor responsibility. Det er bl.a. sådanne basale ting som vished for at leverandøren også eksisterer/supporterer om 2, 5 og 10 år og at denne sikrer en migreringsvej til nye versioner. Det er der nogen der er mere end villige til at betale for.
Ganske enkelt fordi det minimerer risiko og/eller er billigst i det lange løb.
Ivar: Jeg kan ikke se, hvordan det giver mening at sige, at "der ikke er økonomiske fordele ved at anvende OS[S]..". Det kommer da så ganske an på hvem mand er, og hvad man andvender det til??
Og hvorfor skulle en OSS leverandør ikke kunne supportere i lige så mange år som en proprietær? OSS leverandøren har endda sjældnere den samme strategisk interesse i at droppe support på ælde software, for at sælge nye licenser (*host* windows xp).
Og hvorfor skulle en OSS leverandør ikke kunne supportere i lige så mange år som en proprietær? OSS leverandøren har endda sjældnere den samme strategisk interesse i at droppe support på ælde software, for at sælge nye licenser (*host* windows xp).
Det er selvfølgelig korrekt at prisen afhænger af hvem man er og hvordan og hvor meget. Gartners analyse opgør "total cost of ownership" og går således ud over proof of concept perioden og medregner omkostninger til drift, overvågning, produktivitet, kompetenceopbygning, licens, migrering osv.
Mit budskab er blot, at valget af integrationsplatform er strategisk og at licensprisen udgør en mindre del af den samlede omkostning ved at skabe en struktureret, standardiseret og effektiv integrationmetode.
Der går hurtigt religion i den, hvilket også fremgår af debatten her. Det understreger blot nødvendigheden af, at valget af integrationsplatform er strategisk og forankret meget højt i organisationen (over it chefen). På en måde så netop religion ikke får lov til at ødelægge den i forvejen svære proces man igangsætter med implementering af en integrationsplatform.
Mit budskab er blot, at valget af integrationsplatform er strategisk og at licensprisen udgør en mindre del af den samlede omkostning ved at skabe en struktureret, standardiseret og effektiv integrationmetode.
Der går hurtigt religion i den, hvilket også fremgår af debatten her. Det understreger blot nødvendigheden af, at valget af integrationsplatform er strategisk og forankret meget højt i organisationen (over it chefen). På en måde så netop religion ikke får lov til at ødelægge den i forvejen svære proces man igangsætter med implementering af en integrationsplatform.
Når man læser artiklen skinner det da også igennem at Cybercitys beslutning er strategisk funderet.
Du har ret i at den slags ofte er strategisk (selvom det for mig ikke giver mening at man strategisk vælger teknologi). Men, hvordan læser du det i artiklen? De nævner så vidt jeg kan se kun tekniske/operationelle fordele ved et skift.
Prisen for dette kompetencecenter overgår formentlig licensprisen med flere længder. Med andre ord synes jeg licensprisen får et helt forkert fokus og opmærksomhed i denne artikel.
Jeg er enig i at licens-prisen nok er en mindre del af TCO, men, om man opbygger kompetence-center for integration med BEA teknologi eller man opbygger det for JBoss teknologi, mener du der vil være en væsentlig pris-forskel?
Jeg er lidt interesseret i præcist den Gartner rapport du nævner, vel ikke noget du havde et link til? :)
JEE app-servere er noget de mener er "snart" og allerede næsten på "plateau of productivity", jf.:
http://news.cnet.com/8301-13505_3-9...
Mvh,
Søren
Lige min ord Søren Davidsen :-)
Og i øvrigt: Red Hat/JBoss tooling (JBoss Developer Studio) ER en Eclipse med specielle tools til server håndtering og udvikling til JBoss SOA platformen.
Og det virker MINDST lige så godt som BEAs.. har benyttet begge dele :-)
Det er som flere nævner nytteløst at fokusere så meget på selve licensprisen.. det er mest en ting som ledelsen hænger sig i..
Det der batter, er muligheden for selv som udvikler/organisation at kunne påvirke/ændre koden, så man kan bug-fixe selv, og ikke skal vente på en ½-1 år forsinket patch (her snakker jeg real-life erfaring med både IBM WebSphere og BEA WebLogic).. dvs. regnet fra når de indrømmer at der ER en fejl.. og det kan ta lang tid, medmindre man er en Top 100 virksomhed.
Alle laver i øvrigt fejl.. også Red Hat JBoss.. i open source software bliver de ofte bare rettet hurtigere, OG HVIS IKKE, så kan man selv gøre det.
Så kan man bruge sine ressourcer på at udvikle løsninger i stedet for at vente frustreret på en fixpack/patch/service release osv osv.
MEN lad os nu passe på der ikke går for meget religion i det her.
Der er såmænd mange gode Java app. servers på markedet, og BEAs er ikke skidt (dog er den nu er købt af Oracle, og det lover ikke godt.. se bare hva de fik gjort ved Orion serveren.. suk).
Man skal huske at vælge platform ud fra ens behov, og undersøge markedet grundigt...og så være lidt pragmatisk.. det holder bedre i længden.
Information og samarbejde.. det virker bedre end flaming og modarbejde.
Mvh.
Henrik
Og i øvrigt: Red Hat/JBoss tooling (JBoss Developer Studio) ER en Eclipse med specielle tools til server håndtering og udvikling til JBoss SOA platformen.
Og det virker MINDST lige så godt som BEAs.. har benyttet begge dele :-)
Det er som flere nævner nytteløst at fokusere så meget på selve licensprisen.. det er mest en ting som ledelsen hænger sig i..
Det der batter, er muligheden for selv som udvikler/organisation at kunne påvirke/ændre koden, så man kan bug-fixe selv, og ikke skal vente på en ½-1 år forsinket patch (her snakker jeg real-life erfaring med både IBM WebSphere og BEA WebLogic).. dvs. regnet fra når de indrømmer at der ER en fejl.. og det kan ta lang tid, medmindre man er en Top 100 virksomhed.
Alle laver i øvrigt fejl.. også Red Hat JBoss.. i open source software bliver de ofte bare rettet hurtigere, OG HVIS IKKE, så kan man selv gøre det.
Så kan man bruge sine ressourcer på at udvikle løsninger i stedet for at vente frustreret på en fixpack/patch/service release osv osv.
MEN lad os nu passe på der ikke går for meget religion i det her.
Der er såmænd mange gode Java app. servers på markedet, og BEAs er ikke skidt (dog er den nu er købt af Oracle, og det lover ikke godt.. se bare hva de fik gjort ved Orion serveren.. suk).
Man skal huske at vælge platform ud fra ens behov, og undersøge markedet grundigt...og så være lidt pragmatisk.. det holder bedre i længden.
Information og samarbejde.. det virker bedre end flaming og modarbejde.
Mvh.
Henrik
Det der batter, er muligheden for selv som udvikler/organisation at kunne påvirke/ændre koden, så man kan bug-fixe selv, og ikke skal vente på en ½-1 år forsinket patch
Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr. Desuden risikerer man at opnå en binding der er sammenlignelig med vendor lock-in, nemlig en afhængighed af den person der gennemfører disse tilpasninger.
Hvad er det man ønsker at bruge tiden på i integrationskompetencecenteret: Er det at (videre)udvikle og bugfixe middlewareprodukter eller at gennemføre integrationer der understøtter forretningen?
Dette er fantastisk godt eksempel på at platformsbeslutningen er strategisk: Det er vidt forskellige kompetencer der er brug til at rette i kernen af en integrationsplatform og til at designe og udvikle integrationer, hvis formål er at understøtte forretningen.
Søren: Gartners materiale er copyrighted, men her har du referencerne:
Niclos Drakos: Gartner Compares Open Source with Proprietary Solutions
og
Open Source Software: Success Factors and Lessons Learnt
Niclos Drakos: Gartner Compares Open Source with Proprietary Solutions
og
Open Source Software: Success Factors and Lessons Learnt
Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr.
Som udgangspunkt bør man aldrig ændre ting i kernen, som ikke har en god chance for at blive accepteret ind i hoved-projektet. Små hacks, som er nemme at overskue, kan også relativt nemt genskabes til en ny version.
Men i et ordentligt system kan man lave ganske omfattende ændringer uden at røre kernen overhovedet.
Desuden risikerer man at opnå en binding der er sammenlignelig med vendor lock-in, nemlig en afhængighed af den person der gennemfører disse tilpasninger.
Som naturligvis dokumenterer sit arbejde så den næste både kan læse koden OG dokumentationen.
Open source er ikke en silver bullet og kan ikke som koncept gøre fantastisk meget - men det har såvidt jeg kan se ikke nogen ulemper for køberen. Hvis man vælger et forretningsmæssigt sundt system, naturligvis, og ikke et enmands-fritids-hobby-projekt.
Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr.
Er det noget, du ved, eller er det noget du tror? Har du nogen erfaring med dette, eller er det spekulativt?
For mit vedkommende arbejder jeg med til daglig med tilpasset [opensource] software, og vi migrerer, når der er behov for det. For os ville det være en større stopklods at vi ikke havde kildekoden end at skulle bruge nogle mandetimer på at migrere vores modifikationer til næste version.
Hvis man ikke selv har de nødvendige kompetencer, kan man i markedet finde flere (mere end 10) konkurrerende konsulenter/konsulenthuse, som kan. Det er flere end 1.
Med det er jo min erfaring. Lad mig høre din erfaring. Det giver langt mere street credit end løse referencer til formiddagsanalyser fra Gartner Group.
Thomas
Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr. Desuden risikerer man at opnå en binding der er sammenlignelig med vendor lock-in, nemlig en afhængighed af den person der gennemfører disse tilpasninger.
Når det er bugfixing, bliver den slags naturligvis sendt upstream.
Thomas, jeg ved ikke hvorfor du har behov for at dreje diskussionen over i en "langtisningskonkurrence" omkring troværdighed om min person, "street credit" osv. Jeg er ikke med i den retning.
Jeg synes ikke det er passende at begynde at snakke konkrete business cases hos konkrete kunder i et offentlig forum.
Hyggeligt at snakke med jer - og især med min gamle, superdygtige kollega Henrik Rathje!
Jeg synes ikke det er passende at begynde at snakke konkrete business cases hos konkrete kunder i et offentlig forum.
Hyggeligt at snakke med jer - og især med min gamle, superdygtige kollega Henrik Rathje!
Thomas, jeg ved ikke hvorfor du har behov for at dreje diskussionen over i en "langtisningskonkurrence" omkring troværdighed om min person, "street credit" osv. Jeg er ikke med i den retning.
Jeg tisser ikke særlig langt, eftersom jeg har nået den alder, hvor panden er blevet højere og tissetårene er blevet længere.
Jeg har også nået den alder, hvor jeg ikke gider at høre endnu en reference til noget nogen har læst i en bog (eller Gartner rapport) med trykte bogstaver. Jeg vil høre, hvad folk selv oplever. Jeg oplever i mit daglige arbejde, hvordan man kan migrere sine ændringer fra en version til den næste; og undskyld hvis jeg har trådt dig over tæerne, men jeg bliver træt af at høre ordet "umuligt" blive brugt om noget, vi gør og, mere end det, lever af.
Men det kan være jeg skal læse nogle flere af de der Gartner rapporter, så jeg kan få et mere realistisk billede af, hvad jeg ikke kan.
Thomas
Er det noget, du ved, eller er det noget du tror? Har du nogen erfaring med dette, eller er det spekulativt?
Hvis alternativerne er: 1) Opgradere egen kode + 3. parts kode uden ændringer, 2) Opgradere egen kode + 3. parts kode med ændringer, så er det vel ikke usandsynligt at #1 er det billigste?
Spørgsmålet er så om fleksibilitet og "alt det andet" opvejer det, og i øvrigt hvor god man er til at minimere omkostningen ved de ændringer man har lavet (dokumentation?)
(Ivar: Jeg kan iøvrigt ikke finde de Gartner rapporter - burde ellers have adgang til dem gennem uni - og, du mener nok ikke copyrighted, men at de skal betales for :) )
Mvh,
Søren
Hej Søren,
ja de er begge dele!
De er fra "Integration & web services summit, Rome 2007". Men du skulle gerne få nogle hits hvis du søger på Niklos Drakos. Lad for guds skyld være med at søge på Yifim Natis hvis du vil bevare bare en smule tro på OSS og best of breed filosofien... :-D
ja de er begge dele!
De er fra "Integration & web services summit, Rome 2007". Men du skulle gerne få nogle hits hvis du søger på Niklos Drakos. Lad for guds skyld være med at søge på Yifim Natis hvis du vil bevare bare en smule tro på OSS og best of breed filosofien... :-D
Hej Ivar.. i lige måde ;-)
Men jeg er ikke helt enig i din tese:
"Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr. Desuden risikerer man at opnå en binding der er sammenlignelig med vendor lock-in, nemlig en afhængighed af den person der gennemfører disse tilpasninger."
Som andre nævner, så er dokumentation (udviklerens hade-ting-nummer-1) vejen frem.
Vi/jeg har nu altid mødt positive tilkendegivelser/respons fra OSS organisationer, når man finder en bug i deres produkt, og de har generelt været meget hjælpsomme og hurtige til at rette en evt. fejl.
Når det er sagt, så er det YDERST sjældent vi har haft brug for en rettelse i selve kernen af en app. server/platform, som vel er det vi startede med at diskutere :-)..
Til gengæld var jeg en gang nødt til at rette noget for en STOR virksomhed i DK, fordi deres ikke-OS software (pris: 10+ millioner) havde en banal fejl, som producenten nægtede eksisterede!!!?!.. jeg fik en skriftlig ansvarsfraskrivelse fra kunden, og så dekompilerede jeg hele kernen i produktet (Java).. 3000+ klasser.. og fandt fejlen.. det tog inkl. mange diskussioner, og palaver med producenten, 3 uger.. selve fejlretningen var én fil, én linje.. tid: 5 timer inkl. dekompilering). Så udover det faktisk var ulovligt/overtrådte producentens licens, så tog det alt for lang tid, og var alt for "dyrt" i tid for min kunde. Og ved en kommende opgradering af produktet ville de så skulle rette fejlen igen..for den eksisterede jo ikke sagde producenten!.. hmmm
Den case jeg oftest har mødt i OSS, har været ikke helt komplette eller mangelfulde implementationer af standarder i diverse støtte biblioteker (f.eks. webservice stakken i JBoss). Ofte noget de selv påpeger i release docs så man har en idé om hvad problemet kan være..
Vi har så været i stand til at debugge skidtet, finde fejlen ganske hurtigt, og enten: arbejde uden om den, rette den, eller vurdere ud fra den standard som koden implementerer, hvorvidt det kan betale sig at vente på næste release.
Ofte er fejlene små, og nemme at rette, og en senere migrering kan ofte overtages af producenten(f.eks. Red Hat) såfremt man har en support aftale. Som i øvrigt ikke er ret dyre, servicen taget i betragtning.
Men du har MEGET ret i at platform valg er en strategisk beslutning... lige mine ord! Men det oplever jeg nu også at de fleste større virksomheder tager alvorligt, og er klar over.
Jeg har flere gange været involveret i analyser af, hvorvidt det netop ville være relevant for en sådan virksomhed at skifte til en OSS platform.
NB! Jeg er pro-OSS, men ikke for enhver pris!.. kun hvis det på sigt er den bedste løsning for forretningen i virksomheden.
Ofte ender det med en kombination af OSS og ikke-oss.. også for at udnytte de ofte allerede investerede millioner kunden har lagt i deres IT portefølje.
Realistisk og pragmatisk.. nå, nu gentager jeg vist mig selv.. ;-)
- Henrik
Men jeg er ikke helt enig i din tese:
"Og når man så lige ordner et par ting i kernen selv opnår man at migrering til næste release blive umulig eller dyr. Desuden risikerer man at opnå en binding der er sammenlignelig med vendor lock-in, nemlig en afhængighed af den person der gennemfører disse tilpasninger."
Som andre nævner, så er dokumentation (udviklerens hade-ting-nummer-1) vejen frem.
Vi/jeg har nu altid mødt positive tilkendegivelser/respons fra OSS organisationer, når man finder en bug i deres produkt, og de har generelt været meget hjælpsomme og hurtige til at rette en evt. fejl.
Når det er sagt, så er det YDERST sjældent vi har haft brug for en rettelse i selve kernen af en app. server/platform, som vel er det vi startede med at diskutere :-)..
Til gengæld var jeg en gang nødt til at rette noget for en STOR virksomhed i DK, fordi deres ikke-OS software (pris: 10+ millioner) havde en banal fejl, som producenten nægtede eksisterede!!!?!.. jeg fik en skriftlig ansvarsfraskrivelse fra kunden, og så dekompilerede jeg hele kernen i produktet (Java).. 3000+ klasser.. og fandt fejlen.. det tog inkl. mange diskussioner, og palaver med producenten, 3 uger.. selve fejlretningen var én fil, én linje.. tid: 5 timer inkl. dekompilering). Så udover det faktisk var ulovligt/overtrådte producentens licens, så tog det alt for lang tid, og var alt for "dyrt" i tid for min kunde. Og ved en kommende opgradering af produktet ville de så skulle rette fejlen igen..for den eksisterede jo ikke sagde producenten!.. hmmm
Den case jeg oftest har mødt i OSS, har været ikke helt komplette eller mangelfulde implementationer af standarder i diverse støtte biblioteker (f.eks. webservice stakken i JBoss). Ofte noget de selv påpeger i release docs så man har en idé om hvad problemet kan være..
Vi har så været i stand til at debugge skidtet, finde fejlen ganske hurtigt, og enten: arbejde uden om den, rette den, eller vurdere ud fra den standard som koden implementerer, hvorvidt det kan betale sig at vente på næste release.
Ofte er fejlene små, og nemme at rette, og en senere migrering kan ofte overtages af producenten(f.eks. Red Hat) såfremt man har en support aftale. Som i øvrigt ikke er ret dyre, servicen taget i betragtning.
Men du har MEGET ret i at platform valg er en strategisk beslutning... lige mine ord! Men det oplever jeg nu også at de fleste større virksomheder tager alvorligt, og er klar over.
Jeg har flere gange været involveret i analyser af, hvorvidt det netop ville være relevant for en sådan virksomhed at skifte til en OSS platform.
NB! Jeg er pro-OSS, men ikke for enhver pris!.. kun hvis det på sigt er den bedste løsning for forretningen i virksomheden.
Ofte ender det med en kombination af OSS og ikke-oss.. også for at udnytte de ofte allerede investerede millioner kunden har lagt i deres IT portefølje.
Realistisk og pragmatisk.. nå, nu gentager jeg vist mig selv.. ;-)
- Henrik
2- 35 minutter siden - Danske Bank gav gymnasieelev forkert NemID-identitet (35)
- 42 minutter siden - Samsungs Android-tavle-pc kommer til oktober – men koster 7.000 kr. (7)
- 59 minutter siden - Billetlugen rammer muren - igen (27)
- 1 time siden - At rejse er at leve... (18)
- 3 timer siden - CSC sender IE6-aben videre: Sundhedsstyrelsen har fået, hvad de bad om (6)
- 3 timer siden - Novell: Virtuelle applikationer kunne løse sygehuses IE-konflikt (6)
- 3 timer siden - Minister: OK at beskatte danske Google-indtægter i Irland (2)
- 3 timer siden - Kommune dropper Microsoft og hopper i skyen: 'Openoffice er et unødvendigt mellemled' (102)
- 3 timer siden - Forældet Internet Explorer sætter sygehus-it i stå (23)
- 4 timer siden - IBM genopliver vandkøling til ny 5,2 gigahertz mainframe-processor (5)
Relaterede emner
Redaktionen anbefaler
