Oracle has commitment issues over Fusion

Redefining 'Holidays'

By Gavin Clarke in San Francisco, 14th November 2007

OpenWorld A week, former British Prime Minister Harold Wilson is famed for having said, is a long time in politics.

If that's true of politics where destinies turn on a sixpence (or dime), then what does that make a year in application development, where deadlines determine success or failure, and where - so marketing drones keep telling us - business is being done at the speed of the internet?

Oracle, no slouch when it comes to evangelizing the transformative effects its SOA can have on customers' business, on Tuesday recommitted itself to not providing anything approximating a release date for any of its vast array of Fusion-branded development tools, middleware, and applications beyond saying sometime in 2008.

The analysts might know what's really happening, but as executive vice president of development Chuck Rozwat helpfully explained, they are not at liberty to comment as they signed non disclosure agreements (NDAs) in exchange for being briefed by Oracle.

There is one date to be had: Oracle cleared up any possible confusion over what it means when it says "the holidays". The holidays on Oracle's campus means Christmas, not US Thanksgiving, which is next week. Which is a nice gesture towards the Europeans, but - frankly - a little odd given Oracle is a US company.

Senior vice president of server technologies Thomas Kurian said Tuesday the developer preview edition of Oracle Fusion Middleware 11g will be made available in the "middle" of December. The day before Kurian told OpenWorld its middleware and tools preview pack would hit its Technology Network (OTN) "before the holiday season".

Otherwise, it's a case of "calendar 2008" for Fusion Middleware and JDeveloper 11g, and "the first modules" of Oracle's Fusion applications Kurian and Rozwat told press and analysts at OpenWorld.

Which modules from the amorphous project that is Fusion? Oracle wouldn't say. Is Fusion now delayed, with Oracle scrambling to deliver only what it can in 2008 with the rest coming later in the wake of last month's surprise departure of John Wookey, the executive who'd been heading Fusion application development?

No, according to Rozwat, who said Oracle always planned to deliver parts of Fusion in 2008 and that plan is still on track. That contradicts what his boss, Oracle president Charles Phillips, told a "half-way to Fusion" jamboree nearly two years ago.

Complicating the picture further is the ambitious decision to merge many features across the 11g and Fusion middleware and application family.

There are now so many integration points and promises - especially around the (gulp) "mashups" between its software demonstrated at OpenWorld - it seems everything is now moving on all fronts at the same speed... slowly.

It's the position Microsoft found itself in a few years back with Windows Longhorn. That, too, was to be integrated with other yet-to-ship planned new products, such as the next edition of SQL Server.

It's refreshing that Oracle, who's long been competing with Microsoft in the areas of email, business applications and databases, has found a new area to spar with its rival, having bested Microsoft's "sometime in six months" shipping window by committing to the dates of between 1 January and 31 December. ®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

COMMENTS

House Rules Send Corrections

All Reader Comments (1)

Latest Comments

Posted Wednesday 14th November 2007 22:15 GMT

John Hanson

Holiday time for Fusion engineers?

Enforcing analysts sign non-disclosures to view something they don't understand and then not report on what they see is a little confusing to me. Let's see what analysts that refer to BEA as a 'middleware' manufacturer were likely not to have seen, or if seen at least not understood.

In order to provide a migration platform Oracle will have to develop (should I say re-develop if they don't purchase BEA) transformation services for multiple versions of three large ERP platforms. Application level transformation of data may involve as many as 3x(number of versions of each ERP) X (up to a posssible 200x199x198x197x etc possible number of permutations) touch points. By involve I mean design, develop, test, and package these scripts or objects. The difficulty of course is one of significant complexity because Oracle ERP, PeopleSoft, and JDE evolved their internal workings over time and without a complete understanding of the outputs (workings) of the touchpoint internal processes, the interfaces will fail.

Migration is much simpler than 'integration'.

For integration the objects or scripts would be required to meet migration standards but would also have to contain embodied knowledge of the identity of the user and their role (RBAC) in an organization, the business processes, the message exchange method (remember the AS-400 and JDE and backward binary compatibility?), as well as targeted protocols for databases and reporting (future standards?).

Let's omit any consideration of how to deal with past client customizations and how they would be accommodated, protocols for SOA, and securing the Intranet EAI clouds required for the Fusion framework to operate safe from the incessant risk of multiple ports or multiple threads on a well publicized port being referenced before the client's competitor makes any important decision of their own. To not omit this from current Fusion planning and execution (imagining that I am there) would risk some kind of madness within the engineers faced with the prodigous task of bringing this new universe to material form.

Getting back to my original point only stated a different way...what would an analyst see of what Fusion is that they WOULD understand? Signing a non-disclosure only means that we will continue to hear BEA (and therefore Oracle Fusion) described as middle-ware by analysts being secretive.

It makes me cringe whenever I hear the word middle-ware attached to this couple, but then again I don't own Oracle or BEA stock. That would make me a not so good analyst.