Confusion On Fusion Apps At Oracle OpenWorld

Like thousands of Oracle clients and a dozen or so Forrester analysts, I was at Oracle OpenWorld last week.  One of the big news items was the announcement of the availability of Fusion Applications.  The creation of these new applications has been a massive effort, involving many of Oracle’s top software designers and developers working for over five years.  My preliminary opinion, along with my colleagues, is that Fusion apps do have some useful new features and a better user interface than prior Oracle products, as well as providing a more credible SaaS option than Oracle's prior On Demand offerings. 

However, there seems to me to be a lack of clarity as to how Fusion apps fit in the evolution of the Oracle family of apps.   To its credit, Oracle has stated that it is going to be responsive to clients, not forcing them to convert to Fusion nor make staying on existing apps unattractive by not supporting and enhancing those apps.  Instead, it wants to make Fusion apps so attractive that clients will want to adopt them, either (rarely) as a whole suite or (more likely) as step-by-step replacement or additions to existing app products.  Still, that leaves unclear what Oracle sees as the endgame for Fusion vs. its other app products. 

As I see it, there are four scenarios for how Fusion apps will relate over time to the existing portfolio of apps that Oracle has acquired and continues to support through its Applications Unlimited position:

  1. Fusion apps take over and replace the other applications over time.
  2. Fusion apps become yet another app product line, which co-exists with the other apps.
  3. Fusion app features and functions percolate into and are absorbed into the other apps, which persist indefinitely.
  4. Fusion apps provide new categories of applications, which get brought into the other app families as add-ons.

The Fusion Takes Over scenario, pictured in Figure 1 below, was the logical conclusion from Larry Ellison’s remarks, which described Fusion as the next generation of applications.  (BTW, the numbers behind this graphic are not actual or inclusive of all Oracle product lines, but instead are my very crude estimates for demonstration purposes.) However, my conversations with Fusion and EBS product managers indicated that none of them expect this degree of replacement, because few companies will want to undergo the pain and expense of replacing their current EBS, PeopleSoft, or other applications with a Fusion app portfolio.  Even more important, it looks backward to the early days of ERP, when vendors assumed that they could create a single product suite that would meet all the needs of all industries.  But in today’s world, customers require apps that are designed to address the specific, specialized needs of their industries, and that’s not feasible with a single product suite.

Figure 1: Fusion Apps Take Over
(percentage of Oracle application revenue for different application product lines)

 

The second scenario of Fusion apps co-existing with other apps is a logical implication of Oracle’s Applications Unlimited position, in which Oracle supports and enhances all of its product lines, including Fusion.  This scenario has the potential for Oracle to have a portfolio of app product lines, each of which over time can be expanded and enhanced to meet the needs of specific industries.  EBS becomes the product family for manufacturers (say), PeopleSoft for services firms, Retek for retailers, etc.   The barrier to this approach, though, is that existing product clients are not neatly aligned by industry.  Financial services and other services companies use EBS apps, PeopleSoft has manufacturing clients, and Siebel clients cut across industries.  Moreover, Fusion’s role in this model would be either limited to focusing on new and emerging industries and industries not currently well-served by existing Oracle product families, or duplicating industry-focused features and functions of the other apps.  Given Oracle’s investment in developing Fusion, that seems a relatively small return for a big investment.

Figure 2: Fusion Apps Co-Exist With Other Apps
(percentage of Oracle application revenue for different application product lines)

In the third scenario, Fusion apps co-exist with the other Oracle app families, but Fusion becomes Oracle's main vehicle for developing advanced features and functions that cut across industries (industry-specific functions and features continue to get developed in the other app product lines).  The Fusion features and functions then percolate into the other app products.  In other words, the other app families become “Fusionated,” so Fusion takes over the Oracle portfolio in a silent, stealth manner that doesn’t force clients to convert.  The advantage of this approach is that gives Oracle a good return on its investment, creates a cost-effective path for developing product enhancements without duplicating efforts in each product family, minimizes client disruption, and allows the existing product families to focus on developing industry-specific enhancements and extensions.  The obstacle to this scenario, according to the Oracle product managers I talked with, is that many of the advanced features and functions provided in Fusion cannot be transferred to other apps because of the differences in code base and product architectures.  

Figure 3: Fusion Apps Functions Percolate Into Other Oracle Apps
(percentage of Oracle application revenue for different application product lines)

The fourth scenario of Fusion becoming the platform for building a new generation of collaborative apps to my mind is the most promising.  While the Fusion app family duplicates the various financial management, HR management, CRM, supply chain, and eProcurement apps in the existing product families, in practice, there is no reason for a company using EBS core financials or PeopleSoft core HR modules or Siebel core CRM modules to switch to the similar modules in Fusion.  The cost of conversion would far outweigh the relatively small gains in ease of use or Web 2.0 tools that Fusion can provide in these areas.  However, new categories of applications have been emerging around these core legacy apps that are designed to address more collaborative business activities that are more content-rich and analytically intense, such as for project management, case management, services management, or campaign or operations management.  These new app categories take advantage of the Fusion middleware capabilities, and, in many cases, may only work on a Fusion middleware platform.  Moreover, many companies prefer to acquire these new apps on a SaaS basis, which Fusion will support.  In this case, Fusion becomes, not a new generation of applications, but a generation of new apps that can be included in the existing product families as additions to facilitate collaborative business processes.  Meanwhile, the existing product families can continue an evolution toward being more industry focused, building the product extensions needed to meet different industry requirements and needs.

Figure 4: Fusion Provides New Collaborative Process Apps
(percentage of Oracle application revenue for different application product lines)

Oracle of course may not be able to predict which of these scenarios will play out, because that outcome will be determined by how clients react and vote with the software budgets.  However, Oracle ought to have a view as to which it would like to happen, because that will dictate the incentives it will provide to move clients in one direction or another.  My recommendation is that Oracle try to make the fourth scenario the one that becomes reality.

Comments

Fusion Adoption

Thanks for nicely depicting and analyzing the four options. Wanted to share couple of my understanding -
1. Agree with you that 4th option looks promising and I think Fusion will have much more modular play on top of existing apps. Modules (like DOO, FAH, Talent etc) which promises new functions and features and can be integrated with existing Apps will have much more pull than complete suite.

2. It is difficult to percolate Fusion Apps fuinctionality in existing Oracle apps. The design is different. I would rather sense that existing apps will undergo a continuous architecture change towards SOA and will see a bog play in middleware stack. In future this will make migration merely an upgrade experience.

3. I am not sure about Figure 1. Industry Apps like Retek will take much longer to be hit in revenue contribution. Fusion will have to go a long way to include Industry functionalities. What is not clear is JDE. There is no migration tool being built for migrationg JDE customers and I am not sure how many integrations are being built to position Fusion on top of JDE installbase.