||||

Fusion Updates
AMR Research 10/26/06
AMR Research 3/30/2006
 AMR Research 1/20/2006  


 

 

 

 

Fusion Update from AMR Research - 1/20/06

AMR Research gave JDEtips permission to share this AMR Alert with our readers.  Please be sure to visit their Website for more industry alerts. www.amrresearch.com

Oracle Places a Few More Signposts on the Roadmap to Fusion, Friday, January 20, 2006
Judy Sweeney,
Dennis Gaughan

Marking the first anniversary of its announcement, Oracle used beautiful San Francisco City Hall as the venue to update analysts and customers on the progress towards Fusion. Key Oracle executives were on hand to present and demonstrate the Fusion Architecture and toolset. They also unveiled a few more signposts on the road toward Fusion Applications, but the roadmap is still a work in progress.

Charles Phillips began the event by announcing that Oracle is “halfway to Fusion.” Since the full suite of Fusion Applications will not be delivered until 2008, one might ask how Oracle can be halfway to the goal line in January 2006. Whether you agree with the “halfway to Fusion” argument depends on whether you measure completion based on time or on milestones (percentage completed). Oracle made three key points in favor of its halfway argument.

Oracle reports Fusion progress

Fusion has three defined parts: Fusion Applications, Fusion Middleware, and Fusion Architecture. Oracle began by outlining the progress it’s made on all three fronts. >From an application perspective, Oracle has spent the past year working with customers to evaluate the products in its portfolio, determining the best-in-class features and technologies that will be included in its next-generation applications. From the middleware perspective, the company began delivering the middleware, and will be shipping the Fusion development toolset by the end of this week. From an architecture standpoint, the Fusion Architecture has been published, outlining how the portfolio of products will work together. Finally, Oracle also unveiled for the first time more details on the recommended migration path and upgrade strategy for its respective customers.

Oracle’s Point No. 1: With this effort behind it, the company believes the toughest half of the work required to deliver Fusion Applications is complete, and all applications have been certified on Oracle’s middleware.

Myths about Oracle’s strategy
The more telling part of Oracle’s Fusion Application strategy became clear in a session on dispelling the myths of Fusion. In this section, it publicly announced what we’ve all suspected—eBusiness Suite will be the baseline for the new Fusion Applications. Mr. Phillips addressed each of the myths about Fusion.

Myth 1: Oracle will never be able to merge the code basis of these products.
Oracle’s answer: It is not merging the code base of its products. Fusion will be a new product with a superset of the Intellectual Property (IP) from all the products.

Myth 2: Oracle is starting with a blank sheet of paper. 
Oracle’s
answer: The company is not starting with a blank sheet of paper—it is starting with the data model in eBusiness Suite. 60% of the eBusiness Suite is already written in Java, and can be reused. Next-generation products need to be Web services-based and,

therefore, middleware is critical. Oracle already has the middleware, and it has now built a toolset based on accepted industry standards to speed development.

Myth 3: Industry observers say this is never been done before.
Oracle’s
answer: It believes this is just the next generation of products, since there is typically a next generation of products every 5 to 10 years. Oracle has a track record of bringing customers forward on new releases; in fact, 90% of customers are on the latest release.

Myth 4: There is a large or unanticipated cost to the customers. 
Oracle’s
answer: The company has been working with its largest customers that have the option to stay on their existing products and take advantage of Oracle’s lifetime support policy.

Myth 5: You’ll have multiple products (i.e., products for different industries, different geographies, etc.). 
Oracle’s
answer: SAP also has multiple products.

Oracle’s Point No. 2: It is taking the eBusiness Suite code and data model as the starting point for Fusion. 60% of eBusiness Suite will be reused, therefore cutting down the development time in delivering its first release.

Oracle’s Point No. 3: The Fusion Middleware platform is what differentiates its approach from SAP.

Comparisons between SAP and Oracle are inevitable, and when it comes to middleware, Oracle believes it has the advantage. The next release of the Oracle developer toolset, previewed at the event, will be a lynchpin to the success of the overall Fusion strategy. It provides a declarative programming environment designed to make it easy for developers to rapidly assemble new capabilities, an early example of how Oracle is trying to bring IP from all of the different assets it has at its disposal. It is clear that the experience and functionality from PeopleTools factored heavily into the design. The new tooling will certainly get a workout as the Oracle development organization begins the process of building the Fusion Apps.

Another key milestone for the platform will be the release of the JD Edwards and PeopleSoft applications on the Fusion Middleware platform. Oracle suggested that customers preparing for the eventual migration to Fusion Apps can get a head start by transitioning their underlying platform support for JDE and Peoplesoft to Oracle. It would certainly help, but it is an unlikely scenario for most customers who would have trouble justifying the cost of an infrastructure replacement for that reason alone. This recommendation does not signify a change in Oracle’s commitment to maintain support for competing infrastructure on these applications, although no decision has been made about supporting other infrastructure (app servers, databases) for the new Fusion Apps.

Oracle’s recommendation on the path forward

Oracle has promised the path to Fusion will be a migration, not a reimplementation. The recommended steps in achieving that migration strategy are:

1. Customers need to be current on the release of its products. Upgrade now, then standardize on Fusion Middleware and Grid technology.
2. Customers should look hard at what they have customized to see if the functionality exists in current versions of the products, therefore eliminating the customization. Improve master data management, then add Oracle’s BI tools and Fusion reporting.

3. Evolve to
Fusion

Customers can start the evolutionary approach to Fusion by upgrading to the most current version of the application, then adding the middleware components needed to transition. For those that do not choose to migrate, Oracle has agreed to provide lifetime support on all of its applications.

Summary

Oracle’s main message was that it has delivered on what was promised, but the claim of being “halfway to Fusion” falls short due to a lack of details on delivery by product line. Customers have been patient, but the longer they have to wait for specifics on timing and functionality, the harder it will be to jump on the bandwagon. Mapping the individual products to a Fusion delivery timeline is a large project, and will probably take at least another six to nine months before it’s completely fleshed out. In the interim, customers are asking how much the transition will ultimately cost. The lack of specifics has frustrated even many eBusiness customers.

The concept of a common Fusion Middleware platform should play well with Oracle’s larger customers that may already have Oracle, PeopleSoft, and JD Edwards applications in their portfolio. Likewise, the plan to develop a single code base with the ability to add composite applications for differentiated solutions should be very attractive to larger customers and prospective buyers. But the smaller Oracle customer may find it difficult to see the benefits and justify the cost of moving to the Fusion Applications.

© Copyright 2006 by AMR Research, Inc.

AMR Research® is a registered trademark of AMR Research, Inc.