But the hard part, it seems, may not be in the development work itself, but in convincing customers that Fusion Applications—along with Fusion Middleware and the Fusion Architecture—will actually be a seamless upgrade path, versus the major reimplementation that some analysts point to. Wookey met with eWEEK Senior Writer Renee Boucher Ferguson at Oracle's Fusion event here last week to talk about the company's 2007 development plans, and how new functionality there—think reports and analytics—will ease the transition into Fusion Applications, due the following year.

Charles Phillips [Oracle's co-president] said during his speech that 'We're not migrating code, this is a new product.' But then when you talked about having Fusion-esque capabilities in the next suites coming up [in 2007], how do you reconcile these points?

The difference is that when you think about what applications do, they do things like reporting. They take stuff out and do a report. We think we can actually do a lot of that reporting work sooner than changing all the transactional systems. So we will deliver all the Fusion Reports on top of an E-Business Suite, or PeopleSoft Enterprise or JD Edwards application set, and people can start using them. They'll still use the other ones if they want, but they'll use the new stuff, and, oh by the way, when they've done that they'll kind of understand how we're porting over to the new world of Fusion.

Analysts are doubting Oracle's Fusion message. Click here to read more.

But we haven't changed the underlying transactional systems. When we build the next set of transactional systems, which will feed the data to all those reports and do all that other stuff, we're writing new code in this tool set. That's what we're writing new code in. We can't reuse any of the PeopleSoft code. I can't reuse any of the Oracle Forms stuff from the E-Business Suite. I'm actually building a new set of applications that focus on supporting those transactional systems in that next generation.

Reports is a separate thing, right, so we can start placing those components. And reports sounds like no big deal, right? But if you talk to any CIO, the bane of their existence is reporting, so think of 3,000 reports, I don't know what half of them do, and at some point you start thinking of an upgrade process moving forward. They kind of think, 'I know how to move the transactional systems forward, I just look at how the business goals have changed, and I know a couple new capabilities we have, and I'll just get people to move to the new one. I got 3,000 reports—what am I going to do with those things? I've got to figure that out.' So, delivering that early gives them a chance to do that. It is still new code by the way.

Can that new code be migrated when people decide to move to Fusion?

Yes, so then they basically have the Fusion reports, and as they move forward those Fusion reports—obviously we upgrade the data model changes—but those standard reports will be upgraded as part of the standard upgrade. So now you're going from SQR report that works totally differently to a Fusion report with a different technology report, and some data model changes.

You're basically making a big step, so you can say, 'I've got the reporting architecture technology right now, and by the way it turns out it's like 10 times greater than the last reporting technology tool, for a bunch of reasons.' But now I have a very kind of small baby step to take, just based on some data model changes and report layout changes, that I just move forward very quickly. The users basically aren't going to see any big differences moving forward.

Next Page: Fusion features in suites.