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 Oracles Fusion event here last week to talk about the companys 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 [Oracles co-president] said during his speech that Were 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. Theyll still use the other ones if they want, but theyll use the new stuff, and, oh by the way, when theyve done that theyll kind of understand how were porting over to the new world of Fusion.
But we havent 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, were writing new code in this tool set. Thats what were writing new code in. We cant reuse any of the PeopleSoft code. I cant reuse any of the Oracle Forms stuff from the E-Business Suite. Im 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 dont 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 Ill just get people to move to the new one. I got 3,000 reports—what am I going to do with those things? Ive 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 youre going from SQR report that works totally differently to a Fusion report with a different technology report, and some data model changes.
Youre basically making a big step, so you can say, Ive got the reporting architecture technology right now, and by the way it turns out its 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 arent going to see any big differences moving forward.