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?

Saturday, February 11, 2006

Halfway There?

On January 19, Oracle president Charles Phillips declared that Project Fussoin was halfway completed. In particular, he stated that "The hardest part—the requirements—have been done." But is this really the case?

The actions of Oracle's product strategy group seem to dispute the statement that all of the requirements have been defined. As recently as this past week, members of Oracle's Product Strategy team have been continuing to contact user groups to gauge their opinion on the necessity of various features that may or may not be included in Fusion applications.

Oracle has stated previously that it will be relying on its Customer Advisory Boards (CABs) to help shape the direction of Fusion applications. However, many of these groups haven't even met once in the past year. For example, neither the Order Management or Advanced Pricing CAB have yet had a meeting to discuss Fusion. Does this mean that these groups will not be able to have any input into the direction of the Fusion applications, or does it mean the the requirmements are still being defined?

Most importantly, what about database portability? One of the most burning questions amongst JD Edwards and PeopleSoft customers is whether or not Oracle will support Microsoft SQL Server and/or IBM DB2. The consensus opinion amongst Oracle employees is that Larry Elison will be making this decision himself. As of yet, it seems that no decision has been made. I don't believe that Elison has made any public statements on this topic since OpenWorld in September when the said that he felt that the choice would come done to "database portabilty and a little more performance or database portability and a little more security." There is a huge difference in developing applications and middleware that will run on multiple databases vs. those that only need to run on a single database.

Halfway there? I'm not convinced.

Links on this topic:

Mixed Reaction to Oracle Fusion from J.D. Edwards Users

Oracle Claims It's Halfway to Producing Fusion Apps

Analysts Doubt Oracle's Fusion Message

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.

Friday, December 30, 2005

Oracle Certifies PeopleSoft Applications with Oracle® Fusion Middleware

Oracle made this announcement on December 13, 2005. You can read the full press release at this link:

Note the following in the middle of the press release:
Oracle Fusion Middleware for PeopleSoft customers is available for $60,000 per CPU. It features key components of Oracle Fusion Middleware including portal, BPEL, business-to-business integration, business activity monitoring, business intelligence, single sign-on, Web cache and the Oracle Fusion Middleware PeopleSoft adapter. Terms, conditions and restrictions apply

So, if I've got 3 application servers with 4 processors each, then it's going to cost me $720,000 to purchase Fusion Middleware. Additionally, I'm going to have to pay about $160,000 per year for support.

When we purchased PeopleSoft, it came bundled with BEA Tuxedo and WebLogic. Support for the middleware layer is included in our annual applications support fee. Now, it is true that there are components in the Fusion Middleware that are not in the BEA middleware. But do any of these components add any value to a PeopleSoft shop?

PeopleTools bundled with BEA already includes business-to-business integration, a portal, single sign-on, and web cache. The current generation of PeopleSoft applications can't do anything with BEPL and there are no delivered integration points between the Oracle BI tools and current PeopleSoft applications.

So, somebody tell me, what am I getting for three-quarters of a million bucks? Perhaps the more important question in regard to what this means for PeopleSoft customers who eventually want to upgrade to Fusion. Is Oracle going to try to charge customers to use the required middleware at upgrade time? If so, then they haven't been upfront with the customers. If not, then why charge them now? Why not encourage them to get involved with the Fusion Middleware now in order bind them more tightly to Oracle to help stem future defections?

How Do Oracle Support Policies Affect My Ability to Upgrade to Fusion?

As I noted in my last posting, Oracle is offering a direct upgrade path from versions 8.8, 8.9, and 9.0 to Fusion. Those on earlier releases will need to make a multiple pass upgrade. Lately, Oracle has been touting a "Lifetime Support Policy", which suggests that any company that remains on support will be able to upgrade to Fusion. But is this really the case? Let's take a closer look at Oracle's support policies.

For the first 5 years after a release, Oracle will provide Premier Support.
Premier Support provides:
Access to new releases
Technical support
Updates, fixes, and security alerts
Tax, legal, and regulatory updates
Upgrade scripts
Certification with new third-party products/versions

After 5 years, a product goes into Sustaining Support.
Sustaining Support provides:
Access to new releases
Technical support
Pre-existing fixes for your solution
Customers may also obtain customer specific fixes at an additional fee

For three years after a product is no longer eligible for Premier Support, it is eligible for Extended Support. Extended support provides companies with all of the features of Premier Support except for certification with third-party products and versions. I don't have any good insight as to how much Oracle is charging for Extended Support.

For those companies that are planning to upgraded to Fusion, what is most important is that Upgrade Scripts are included in Premier Support but not in Sustaining Support. This means that unless a company is paying for Extended Support, there is no guarantee that Oracle will support that company with any issues that arise during the upgrade process. Here are the release dates for versions 8.8 and higher of CRM, Financial/Supply Chain and HRMS products. As it stand, these will no longer have Upgrade Script support 5 years from the dates shown below:

Q4 2002--CRM 8.8 and HRMS 8.8
Q4 2003--Financials/Supply Chain 8.8
Q4 2004--CRM 8.9 and HRMS 8.9
Q3 2005--Financials/Supply Chain 8.9

Now, let's look at the Fusion Roadmap. Oracle has stated publicly that the first Fusion Applications are planned for 2007 and a Fusion Application Suite is scheduled for 2008. However, they also acknowledges that the timing these plans may change. If we assume these dates to be accurate, however, this means that HRMS and CRM users on release 8.8 will have passed the Premier Support window well before a full Fusion Suite is available. For HRMS users, this is particularly critical since they cannot operate reliably without tax support. The picture isn't much brighter for Financial/Supply chain users since, based in this roadmap, they would likely only have a few months to execute an upgrade to maintain uninterrupted support.

Unless Oracle changes their support policies, it doesn't seem likely that companies on 8.8 versions will have the opportunity to wait for Fusion. In fact, 8.9 users are also at risk if the Fusion suite is delayed significantly.

My recommendation:
Companies that are currently on 8.4 and that want to be on the Fusion path should be immediately planning to upgrade to version 8.9 now or to quickly move to 9.0 when it is released and to be prepared to pay for Extended Support. Companies that are currently on 8.8 should be planning to upgrade to version 9.0 sometime in 2006 or 2007.

What's in the Pipeline for new PeopleSoft Releases?

On its web site, Oracle describes Fusion as "...Oracle's vision for next-generation enterprise technologies, applications, and services that will revolutionize business. The core of this vision is to protect customer investments and to extend and evolve the best functionality from PeopleSoft, JD Edwards, and Oracle product lines." Development is continuing on existing product lines. But, evenually, they will all merge into the new Fusion product.

As of this writing, the current version of PeopleSoft applications is 8.9. This version was released in the latter half of 2005, after the Oracle takeover. However, most of the work that was done in regard to defining the functions and features of this release were done under the prior regime. By the time the merger occurred, the 8.9 features had been frozen and most of the code had already been written.

Oracle has promised a 9.0 version of PeopleSoft Enterprise. I would expect that it will probably come out sometime in the third quarter of 2006. Unlike previous major releases, 9.0 will not include a move to a significantly different version of PeopleTools. When version 8 was released, it required a move to PeopleTools 8. PeopleTools 8 was significantly different than earlier releases. 7.5 applications were not compatible with 8.0 tools and visa versa. This is not the case for PeopleSoft 9.0, which will be released on PeopleTools 8.48. Earlier versions of PeopleSoft applications from 8.4 to 8.9 will be supported on on the 8.48 Tools release. There are no major architectural or systemic changes between 8.9 and 9.0. So, while the version number makes this seem like a major release like version 8, it is really more of a dot release. I expect that the difference between 8.9 and 9.0 will be comparable to the difference between 8.8 and 8.9. I expect that the only reason that they are calling it 9.0 is that it sounds a whole lot better from a marketing perspective than to call it 8.91 or something like that.

Version 9.0 will be the last release of PeopleSoft Enterprise. Once it's in the can, all development efforts will move to Fusion. Oracle has announced that there will be a direct upgrade path to Fusion from 8.8, 8.9, and 9.0 versions of PeopleSoft Enterprise. Organizations on earlier releases will only be able to upgrade to Fusion by first upgrading to one of these releases.

Next time, I'll take a look at the current support polices for PeopleSoft applications and what they mean for companies that are thinking about migrating to Fusion.