Sats på BEA, Oracle!

Et nyhedsbrev fra Oracle er landet i min indbakke:
Citat:

May 5, 2008 We are pleased to announce that Oracle has completed its acquisition of BEA Systems, Inc., and BEA is now a wholly owned subsidiary of Oracle.

Brevet fortsætter med den ikke overraskende melding at ? alt forsætter som det plejer, alle dine investeringer er sikre, uanset om du har satset på Oracle eller BEA og at Oracle fremover vil køre med begge produkt-porteføljer. Og sådan vil det nok være et par år, hvorefter Oracle højst sandsynligt vil konsolidere sine produkter.

Efter Oracles annoncering af opkøbet af BEA havde en af mine bekendte besøg af et par (selv-)tilfredse Oracle-folk, som var af den sikre overbevisning at Oracle ville nedlægge BEA og inkorporere BEAs funktionalitet i Oracles middleware. Det skal dog retfærdigvis siges at de ikke var involverede på strategisk niveau i Oracle.

Fra min personlige helikopter ser verdenen noget anderledes ud. Oracle havde alle muligheder for at udkonkurrere BEA: De har mange kunder og mange store kunder, de var allerede solidt positioneret hos kunderne, deres udviklingsbudget er større end BEAs og deres middleware var billigere end BEAs. Jeg kan ikke få øje på en eneste grund til, at de ikke fejede BEA af banen.

I stedet valgte de at købe BEA til den ganske pæne pris af $8.5 mia.

Den eneste årsag jeg kan komme på er, at deres produkter ganske enkelt må være ringere end BEAs, både strategisk, hvilket underbygges af Oracle dårlige placering i Gartners Magic Quadrant for middleware, og praktisk i det daglige, som ubekræftede rygter siger (jeg kender nogen, der har arbejdet med Oracles middleware ? men læg ikke for meget i det).

Et eller andet sted har jeg ikke kunnet sige mig fri for fornemmelse af, at Oracle har opfundet deres middleware for at sælge flere databaser (deres middleware skulle være svinebundet til Oracles database på samme måde som Microsofts BizTalk er svinebundet til SQL Server). At bruge en database-hammer til at hamre på middleware-søm er ikke nogen god opskrift på succes.

BEAs platform er straks mere åben. Er det for meget at håbe, at Oracle, når tiden kommer til at konsolidere sine produkt-porteføljer, tør skære båndene til sin database og lave et mere rent produkt, baseret på de principper som BEA kører med i dag?

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Flemming G. Jensen

Den eneste årsag jeg kan komme på er, at deres produkter ganske enkelt må være ringere end BEAs, både strategisk, hvilket underbygges af Oracle dårlige placering i Gartners Magic Quadrant for middleware, og praktisk i det daglige, som ubekræftede rygter siger

En anden og langt væsentligere årsag er Bea's mange store kunder. Man skifter jo ikke lige sin middelware ud over natten, fordi en direktør har været på betalt studietur til USA eller en arkitekt har læst et par white papers. Bea har et rigtigt godt kundegrundlag, som Oracle nu får direkte adgang til med andre produkter end databasen.

Nu er både Bea og Oracle middelware produkter jo efterhånden en meget omfattende produktpalette, så hvad sammenligner dine kilder egentlig? Java serveren, enterprise service bussen, BPM, udviklingsværktøjer eller ?. Jeg har fornøjelsen af at arbejde med dele af begge produktlinier, og min erfaring er, at de har hver især har deres styrker og svagheder. Begge platforme er i øvrigt komplekse, så det tager lang tid at lære bare en del af produkterne at kender. Oracle Enterprise Server i version 9.x var reelt i betatest host kunderne, og det var meget uheldigt for Oracle's ry på det marked. På den anden side er det jo en velkendt udviklingsmodel.

Hvordan begrunder du, at Bea skulle være mere åben end Oracle? De bygger begge på åbne standarder ( i Java verden kalder vi også JCP implementeringerne "åbne", fordi der er blevet skabt ved et ligeværdigt og åbent samarbejde mellem community medlemmerne) At Bea så i flere tilfælde har været lead på udarbejdelsen af JCP'erne er en anden sag. Oracle deltager også aktivt i JCP processen

Oracle har valgt en anden strategi end SAP og er gennem de sidste år vokset ved at købe sig ind på nye markeder. Hver gang dukker der synspunkter op som dine. Med god grund iøvrigt for det er jo i realiteten monopoler vi taler om. Men så vidt jeg kan se så har Oracle holdt sine løfter, f.eks. med support af tilkøbte produkter på andre databaseplatforme, f.eks. J.D. Edwards og Sibel på DB2 og SQL Server. Oracle stoppede heller ikke udviklingen af InnoDB, selvom alle så det opkøb som et direkte angreb på MySQL.

Jeg synes, at det bliver spændende at følge udviklingen af begge partforme og se dem konvergere.

By the way: Hvornår har nogen infrastruktur eller middleware efter Gartner Magic Quadrant?

  • 0
  • 0
Jesper Stein Sandal

Min umiddelbare analyse er, at Oracle har skiftet strategi omkring dets opkøb siden balladen omkring PeopleSoft. Det ser langt mere ud til, at firmaet er tilfreds med at holde liv i udviklingen af de selvstændige produkter end at løbe risikoen for at miste kunder ved at tvinge dem over på en Oracle-platform.

Selvfølgelig vil de gerne have kunderne over på Fusion-versionerne af deres software, når den tid kommer, men jeg tror ikke, de har så travlt med det, som de havde for et par år siden. Måske også fordi Fusion-udviklingen ikke helt går så stærkt, som Oracle havde håbet.

Med andre ord tror jeg, at Oracle indtil videre har det fint med at bevare BEA nogenlunde intakt. Også selvom det betyder, at de skal vedligeholde flere parallelle produkter.

  • 0
  • 0
Peter Nørregaard Blogger

Du har nogle gode pointer, Flemming. Men uanset kundebase, så er den nu ikke så stor at den i min optik umiddelbart kan retfærdiggøre en pris på $8.5 mia. Det kan på den anden side heller ikke retfærdiggøres at betale $8.5 mia. for en god produktsuite – så der er nok tale om en kombination.

Jeg har læst om at Oracle ser ud til at holde hvad de lover når de opkøber, hvilket er glædeligt. Som du siger, vil de to produktlinjer konvergere og det er her at Oracle gerne må tænke mere som BEA som har holdt sig database-agnostiske. Oracle har, i hvert fald historisk, haft mottoet ”it’s all in the database, man!” (citatet stammer fra http://www.youtube.com/watch?v=uOQcjvUHZ0k – som er lidt ond mod de store på SOA-markedet – undtaget TIBCO, som har produceret videoen).

Omvendt har BEAs produkter (som andre middleware-produkter) også sine udfordringer med performance som måske kan afhjælpes med en tættere binding med færre lag ned mod databasen. Men jeg forventer at Oracle agerer efter at systemlandskaberne også fremover vil være heterogene.

Rapporten fra Gartner var så vidt jeg husker ”Magic Quadrant for Application Infrastructure” for en gang i 2006 eller 2007. I en analyserapport blev Oracle den gang betegnet som en ”sleeping giant” som vi ville mærke noget til når den vågende, og det gjorde vi da den spiste BEA til morgenmad.

  • 0
  • 0
Ivar Albæk Hansen

Jeg synes du mangler nogle nuancer i din vurdering. Jeg vil give dig ret i at Oracles middleware kunne være bedre, men det samme kan du sige om de øvrige produktstakke fra de helt store "komplette" leverandører (SAP, IBM, MS, Oracle, JBoss).

De har alle deres styrker og svagheder og nu du nævner Gartner så er netop Gartner gode til at lave nuancerede sammenligninger. I øvrigt er det helt forkert at sige, at Oracles middleware placeres dårligt i Gartners ”magic quadrant”.

Jeg ved dog ikke rigtig hvad vi skal bruge disse sammenligninger til. Jeg tror kunderne dels går langt mere op i at udnytte den investering de allerede har (kompetencer, infrastruktur m.v.), dels at vælge en teknologi der passer ind i deres strategi. Valget af platform er strategisk – det er ikke akademisk.

Jeg håber iøvrigt (og forventer på baggrund af erfaring) at Oracle vil holde hvad de lover, og supportere begge stakke i lang tid og sørge for en fornuftig migreringsvej.

Når du siger at ”Oracles middleware er svinebundet til deres database” så er det et udmærket eksempel på en akademisk holdning, som jeg desværre har set for tit hos højt profilerede enterprise arkitekter (dette er ikke personligt rettet mod dig, men en generel betragtning).

Jeg fatter det simpelthen ikke: Hvorfor er det ”forbudt” at levere persistens i en velfungerende og supporteret database? En database som man allerede har kompetencer på, og som både er licensmæssigt og teknisk embedded i middlewaren?? Og hvorfor må jeg ikke ikke bruge en Oracle database til mit SOA repository – det er trodsalt yderst forretningskritiske data??

Det åbenlyse svar er selvfølgelig åbenhed, som du selv er inde på. Man skal kunne vælge den database man vil, og skifte den når man har lyst. Okay, hvem har brug for det, og hvorfor egentlig?

Lad os tage eksemplet enterprise service bus (ESB), som nok er blandt de mest aktuelle SOA komponenter på det danske marked om et årstid eller to: Oracle bruger deres egen embeddede database i deres ESB (ligesom de andre!!!): Den holder styr på dynamiske metadata bl.a. omkring connections og transformationer. Den installeres som en del af produktet og kræver ikke absolut Oracle DB administrator kompetencer på ekspert niveau. Databasen er en vigtig del af en infrastrukturkomponent, der bare skal fungere og performe 24*7, og hvem i denne verden har lyst eller grund til at sætte denne hyper-forretningskritiske komponent ud af kurs ved at udskifte den ene halvdel af infrastrukturen? Her skal der stærkere argumenter på banen end blot ”for åbenhedens skyld”. Det er jo ikke sådan at man ikke kan connecte til andre databaser end Oracle.

Hvis man er utilfreds med sin Porsche motor skifter man motoren (eller bilen) – man skifter ikke bare krumtap-akslen til en Fiat.

Jeg har mødt en arkitekt eller to, der nu kunne finde på at sige at en ESB slet ikke skal have en database, men den diskussion er efter min mening akademisk.

Leverandørbinding kan faktisk være ”okay” set udfra en økonomisk synsvinkel, og at dømme efter Microsofts succes kan åbenhed da heller ikke stå øverst på alles dagsorden.

Her er det i øvrigt værd at bemærke, at Gartner har analyseret sig frem til, at omkostningen ved open source er ligeså stor som på kommercielle løsninger – alle parametre taget i betragtning.

  • 0
  • 0
Peter Nørregaard Blogger

For så vidt angår bindinger mod databaser, ja, så er det rigtigt at de fleste leverandører (undtaget BEA, så vidt jeg ved) bygger oven på deres egne – jeg har fx lige siddet dagen igennem med Microsoft for at høre om BizTalk, og den er (svine-)bundet til SQL-server. Og nej, jeg tror ikke at der er mange, der overvejer at skifte databasen ud under fødderne på applikationerne, for hvorfor skulle de det?

Men det er heller ikke kernen i mit argument – snarere det modsatte: Alle har allerede et database-produkt og det er ikke nødvendigvis Oracle. De fleste af mine kunder har en god idé om hvilken IT-strategi de har, og den inkluderer ofte et strategisk valg af den databaseplatform, de ønsker at bevare deres relativt homogene miljø på. Det er trist, hvis kundernes valg af database en gang i fortiden skal afgøre, hvilke SOA-produkter de på den baggrund kan få lov til at købe efterfølgende.

Hvis kunderne er bundet fra top til tå til én leverandør begrænses konkurrencen om at levere det bedste SOA-produkt. Så set fra mine kunders synsvinkel er en binding mod en underliggende database et problem, lige så snart databasen ikke er den samme de har i forvejen.

Om det så er rimeligt og fremsynet for en kunde at binde sig til kun at ville have én database-leverandør er en anden diskussion. For det kunne de jo bare lade være med, og leve med et mere heterogent miljø – med de omkostninger dét nu engang har, fx. til licenser.

Jeg er ikke blind for, at hvis alle skulle anvende ANSI SQL-92 for at bevare en løs kobling mellem systemerne, så ville vi være afskåret fra at anvende en pæn del af fremgangen i database-teknologier siden '92. Jeg er også klar over, at en løs kobling mellem applikation og database typisk giver et performance-overhead. Derfor var jeg da også noget skeptisk, da IBM sidste år stillede sig op på en SOA konference og sagde "Don't design for performance – design for flexibility". Udsagnet understøttes selvfølgeligt af Knuths "premature optimization is the root of all evil" men på den anden side er performance stadig et problem, særligt og ofte i SOA-løsninger.

Men uanset hvad, ville jeg være ked af hvis en løsning med BEAs kvaliteter skulle blive ændret til at favorisere Oracle i forhold til andre databaser.

Om placering i magic quadrant, så er jeg rimeligt sikker på hvad jeg har læst - men jeg ikke kunnet genopfriske minderne da jeg ikke har adgang rapporten længere. Hvis Ivar eller andre har et eksemplar, som I kan vise mig, så korrigerer jeg gerne mine udsagn.

Tak til både Ivar, Jesper og Flemming for nogle gode, velargumenterede indlæg!

  • 0
  • 0
Peter Nørregaard Blogger

Jeg sidder her med et udbud til en statslig institution. De beder os om at redegøre for om løsningen er teknologi-neutral i forhold til underliggende software og hardware platforme - eller med andre ord, om den åben for at kunne afvikles på andre platforme.

Så ud over min personlige mening om at det er en god egenskab, så har vi altså her en kunde, der specifik efterspørger at deres integrationsplatform er åben.

  • 0
  • 0
Ivar Albæk Hansen

Hvis de beder dig redegøre for om løsningen er teknologi-neutral er der jo ikke tale om et ufravigeligt krav om at løsningen skal være åben. Du skal bare redegøre for hvor løsningen eventuelt ikke er åben og/eller hvilke platforme den kan afvikles på. Oracle ESB/BPEL og database kan jo fint afvikles på en lang række platforme, så den er et oplagt valg her ;-)

Jeg kender godt denne slags formuleringer i udbud, og jeg har været med til at strikke åbne løsninger sammen, og set kunden vælge en førende proprietær platform. Surt.

Jeg må hellere understrege at jeg ikke er modstander af åbenhed, jeg er blot ikke overbevist om at åbenhed betyder så meget for kunderne når det kommer til stykket.

En ting jeg er endnu mere overbevist om er, at kunderne ikke har én væg-til-væg platform. F.eks. har jeg eksempler på flere kunder der har både Biztalk og Oracle BPEL/ESB og jeg har også hørt en stor dansk forsikringskoncern gladeligt fortælle at de havde 7 forskellige ESB platforme.
Hvorfor ikke, blot de kan bringes til at tale sammen - og det kan de takket være åbne standarder. Piece of cake.

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