The Oracle Fusion Blog

Oracle is touting Project Fusion as an application that will contain a "superset of features" from Oracle, PeopleSoft and JD Edwards. What does this really mean to companies that are operating their businesses on current versions of these applications? As an IT manager at a company that relies heavily on PeopleSoft Enterprise applications, path from PeopleSoft to Fusion is key to my and my organization. How forthright is Oracle Corporation being with its customers?

Wednesday, January 11, 2006

What will Fusion Look Like?

Chances are, the look and feel of Fusion Applications will be closer to that of the PeopleSoft Enterprise appliations than to any of the other current product lines. PeopleSoft was the first of the major ERP vendors to commit completely a pure Internet architecture for its applications. It has been close to 6 years since the release of Peoplesoft 8.0, which completely abandoned any traditional client/server connectivity. As a result of their early commitment to a pure web-based system, PeopleSoft was significantly ahead of JD Edwards and Oracle in regard to desigining a solid user interface using only features available in a browser-based environment. Furthermore, PeopleSoft had a large dedicated User Experience group. These people had been doing extensive testing to determine how best to optimize the browser-based user interface and understand what it is that users want. For these reasons, Oracle is most likely to turn to the former PeopleSoft development team to design the UI and to craft the look and feel of the applications.

Oracle has stated publicly that Oracle Forms will not be utilized in Fusion applications. Where Fusion applications will probably diverge from existing PeopleSoft applications is that while PeopleSoft applications are all deployed using HTML, Fusion applications are expected to utilize DHTML. This change will allow the browser-based applications to look and feel more like traditional client/server based systems. One example of where DHTML will improve performance is that with HTML, any change to a screen requires the entire page to be refreshed. So, by only refreshing those areas of a screen that need to react to the user's actions, the page is updated more rapidly and more smoothly than if the entire page needs to be redrawn. Another potential use of DHTML is the addition of drag-and-drop capabilities to the application. Users have become so accustomed to this type of functionality in their Microsoft applications that they miss the ability to do this in web-based programs.

If, in fact, Oracle fully commits to DHTML and if the former PeopleSoft user experience team is given a relatively free hand to create a great front-end, the likelihood of having an excellent UI in Fusion applications is high. I expect that Fusion applications will have a more user-friendly front end of any current web deployed applications.

Wednesday, January 04, 2006

So, Will Fusion Really be a Superset of Product Features?

In their published white paper "Oracle Applications: Committed to Your Success", Oracle states that "Because Fusion is a “superset of features,”with a product-feature genealogy from Oracle,PeopleSoft, and JD Edwards, a much richer set of industry-specific features is now available in the release." The High-Tech defintion of a superset is "A set that includes other sets within it, which are called subsets. For example, a software or hardware upgrade may be a superset of the previous version in that it can do everything the previous version can do and more." So, by definition, Fusion applications should do everything that existing PeopleSoft, JD Edwards, and Oracle eBusiness applications can do. But is this true, or even possible?

Let's take a look at a feature that exists within PeopleSoft applications that does not exist with Oracle eBusiness applications. I'm referring to SetID. The concept of SetID allows multiple Business Units to share a common set of setup values while others do not. So, for example, PeopleSoft Purchasing Business Units shares information with PeopleSoft Payables Business Units that have the same SetID. With two SetIDs, you could have two sets of Purchasing and Payables Business Units existing side-by-side and not conflicting with each other. Each set of Business Units could have a Vendor ID 10001, but with each of these assigned to a separate SetID, there would be no conflict. Similarly, each set of Business Units would be sharing a completely different set of ChartFields. Oracle eBusiness applications have nothing comparable to SetID. While I'm not an expert on eBusiness, I do not believe that there is any clean way to have the type of scenario that I've just outlined in a single eBusiness instance. So, how will Fusion handle this? If SetID doesn't exist within Fusion applications, then PeopleSoft Enterprise that rely on this feature will be left out in the cold. Oracle has stated that the eBusiness data model will be used as the foundation for Project Fusion. Adapting this data model to include SetID will be an enormous task, given how prevelent it is in the PeopleSoft data model. Is is reasonable to expect that SetID will be added throughout the data model in order to accomodate PeopleSoft Enterprise customers that need it?

But we don't need to speculate to see that Oracle is already planning cutting back on features. Here is one example that shows that Oracle is clearly not committed to including all PeopleSoft features in the Fusion applications. PeopleSoft Order Management provides users with the ability to key in a One-Time address when entering an order to ship product to a location that is different from any of the ordering customer's existing addresses. This is commonly done if the customer is acting as a reseller and the order is being drop shipped directly to the customer's customer. Oracle applications do not have this feature. Any shipping address must be permenantly tied to the Customer Master. Oracle has no way to ship an order to an address that does not exist in the customer database. Now, if Fusion is truly going to be a superset, then the Order Management system in Fusion must support the concept of a One-Time address. There is currently a flurry of discussion amongst users of PeopleSoft Order Management due to the fact that it has been suggested to them that the One-Time address feature may be excluded from Fusion. PeopleSoft users that rely on this feature are finding that they are being forced to defend their use of this feature and to explain why it would impact their business if they were to lose it. We know that there are many more companies using eBusiness Order Management than there are using PeopleSoft Order Management. What this sounds like to me is that, in this case, rather than planning a "superset" release, Oracle is planning a "majority rules" release.

The loss of features that are key to some customers is probably inevitable if Oracle is going to keep to its announced schedule. It isn't realistic to expect that a true superset can be developed in the two to three year timeline that Oracle has given itself to bring out the first generation of Fusion applications. However, if Oracle doesn't own up to this fact with its customers, many of them are probably in for a rude awakening when the first release of Fusion becomes available.