Oracle proposes to buy BEA
Oracle
today confirmedthat it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.This acquisition has been long-discussed so I can't say I find the news particularly surprising, particularly with Carl Icahn recently
upping his stake in the company. I think this just makes it more likely that Oracle's proposal will be accepted.
This is primarily as a market share grab by Oracle. It does plug some gaps in the portfolio - particularly around business process management (based on BEA's Fuego acquisition), where Oracle only has basic BPEL web services orchestration; adds some telecoms vertical market capabilities to complement Oracle's vertical market push and the virtualisation work that BEA has done with the WebLogic Virtual Server Edition. Also, there's the opportunity for Oracle to tap into the healthy Tuxedo base. With a significant chunk of Oracle's profitability coming from maintenance, the revenue from BEA's customer base will suit its business far better than it did BEA which was suffering with its inability to grow license revenues.
This is yet another example of the bigger specialist players getting squeezed out by the industry goliaths - IBM, Microsoft, Oracle, SAP - and the open source, smaller best-of-breed players. SAP's recent acquisition of Business Objects is another example (although that did plug a few more gaps). It leaves some of the other bigger specialist players - TIBCO, SoftwareAG (and to a lesser extent Progress and Red Hat) in an interesting position. On the one hand they will be more attractive, particularly for SOA and BPM, to customers looking for an application-independent infrastructure offering. On the other, though, taking market share for those customers from BEA is one thing: taking it from Oracle quite another. Ultimately, IBM is the big beneficiary in this regard.
In summary, then, I see: the acquisition going ahead; BEA's customers looking worried as they see themselves with an application-dependent infrastructure stack; IBM looking happy at the prospect of providing those customers with an application-independent alternative; the likes of TIBCO and Software AG pondering their options; and SAP and Microsoft carrying on in there own sweet way.
Labels: BEA, BPM, ibm, Microsoft, Oracle, Progress, Red Hat, SAP, SOA, Software AG, TIBCO
MWD FM SOA interview: TIBCO
We're nearing the end (for now - we have more planned, but not for a little while) of a series of SOA vendor interview podcasts with
this one, which we conducted recently with Rob Myer of TIBCO. Rob works in Product Management at TIBCO with responsibility for SOA.
We ask the usual four questions, and along the way swing by some interesting conversation points:
- What you need from infrastructure in order to move towards enterprise-wide SOA, and what TIBCO learned from telecoms companies' service platform requirements
- The challenges associated with the WS-Policy, WS-Management and WSDM standards
- The application of CEP (complex event processing) technology to managed service delivery in the context of SLAs.
This podcast episode is 34'28" long. The podcast episode lasts 25'34". You can download the audio
here or you can
subscribe to the feed.Labels: MWD, podcast, SOA, TIBCO
TIBCO's ActiveMatrix and 4GL for SOA
We've been meaning to blog about TIBCO's ActiveMatrix product family for a few weeks now, since we were briefed on it in December. However it took a while for us to get to a point where we felt we had something particularly "aha" to say about it.
What makes ActiveMatrix so potentially valuable is also what makes it a challenge. As TIBCOer Rourke McNamara said in a
blog entry from Gartner's Application Integration and Web Services Summit: "Explaining what ActiveMatrix does in 90 seconds isn?t easy." Actually explaining it's value is more challenging, because it's not what you might expect from TIBCO.
TIBCO talks about "service virtualisation" and describes the core element of ActiveMatrix - the ServiceGrid product - as a "network of service containers" with "embedded policy management for service governance" and "JBI and SCA support for service deployment and provisioning".
These things are all true, and they're all cool.
But what does that really *mean*, in really straightforward terms? After talking to numerous journalists and clients about ActiveMatrix over the past weeks, we've evolved our introductory explanation to this one, when talking to non-expert IT audiences:
Back in the day, a big challenge faced by large organisations trying to develop and deploy systems was how to create systems relatively quickly, that were quick to change, in complex multiplatform environments. In those days the multiplatform issues was one of 16- and 32-bit Windows, Mac and OS/2 clients; Solaris, AIX, HP-UX, OpenVMS servers; and various kinds of databases and network protocols (this was when IPX/SPX and SNA were as interesting as TCP/IP).
A whole range of "second generation 4GL" environments were created which aimed to help. They married a high-level abstract programming language (the 4GL) to a virtual machine which was ported to all the major platforms and which hid the details of the operating environment - client, server, database, network.
Now let's fast-forward to today. Java and JEE and web-based application designs helped with some of that old multiplatform nightmare, but it's not the only game in town. What's more, now we're looking at SOA, the challenge today isn't so much about building discrete systems; it's about finding a consistent way to build and integrate system elements that can talk to each other within various parts of our companies, and also across different companies and whole supply chains.
In short we have another version of the same problem, only this time the multiplatform aspect is at a higher level - and the scope and scale of the operational environment are much bigger. Now we struggle to get "plain Java", JEE, .NET and other modern application containers to talk to each other, as well as other "legacy" application platforms - and Web Services protocols and standards are only a partial answer here at best. Even if protocol interoperability gets working better we're now looking at an environment which is widely distributed, and which may not be 100% under any one party's control.
So if we're to try and address today's challenge for SOA - to enable people building and integrating services to just concentrate on the core logic of what they're doing rather than getting stuck in the weeds of environment-specifics - we need something like the old 4GL virtual machine, but with lots of extra capabilities - like service provisioning (think about telecoms service provisioning if you know that industry) , and policy-based operational and lifecycle management of services.
That's what ActiveMatrix does. It provides a virtual machine environment for the SOA age.
As an aside: Why is ESB not the answer, and why is ActiveMatrix not an ESB? Because ESBs concentrate on solving just one part of this conundrum - the operational communication between services. From the developer's perspective the ESB is pretty much invisible (intentionally), and doesn't offer any "virtual machine" facilities to that audience. ActiveMatrix works on top of, around, and underneath ESBs.
Of course there's a proprietary element - although ActiveMatrix is built around JBI / JSR 208 and elements of the SCA specification, the container design itself is unique to ActiveMatrix. Interoperability is standards-based through JBI, but of course interoperability with something else is not the same as "swappability".
So here's a couple of interesting questions. Do companies pursuing SOA know they need this, and does TIBCO have the credibility to provide it? And is there enough momentum in the SOA movement to get the mainstream of companies to the point where they need ActiveMatrix, or something like it?
The credibility question is a good one, because it certainly took me a while to work out what TIBCO was doing with ActiveMatrix. I saw it completely as an integration vendor moving into SOA, and was completely unprepared for what TIBCO was trying to tell me - for a while it just didn't compute. We're going to need some excellent customer examples, well-explained, to really help people get in the right frame of mind to hear what TIBCO's trying to say here.
The second question is concerning to me as a student of IT industry history. The truth is that the history of the industry is littered with examples of situations where "movements" were cynically abandoned by vendors in favour of newer, shinier things, just as they got to a tipping point. If you can dupe your customers well enough, you can sell them A, wait until they get familiar with it, and then tell them that A is last year's model, and sell them the virtue of A'. Example: the demoralising arrival of
SOA 2.0.
Many say that SOA itself is one of these cynical reinventions, and there is a grain of truth in that (but only a grain, I'd say). I believe that SOA has real value - and that in the context of achieving that value companies will need facilities like they can get from ActiveMatrix - but my concern is that we'll get derailed by the "next big thing" before we can all realise that value.
Lastly, a disclaimer: TIBCO is an occasional client and we provided some input to help them refine their ActiveMatrix communications.
Labels: 4GL redux, SOA, TIBCO
