Cold Fusion
We live in times when good things to worry about range from “which steroid era players belong in the Hall of Fame?” to “can our species survive climate change?” Given the range of real things to be concerned about, JD Edwards users do not need to spend any time worrying about Oracle Fusion Applications.
When Fusion was first announced, SAP and other Oracle competitors started calling it Con-Fusion. Three years later, a modest level of confusion about it still remains. The giant media event Oracle held at San Francisco city hall early in 2006 to explain Fusion left as many questions open as it answered. It also left an impression that refuses to go away within the JD Edwards community that the day will come when Oracle will try to force all of its application customers to go through an expensive and painful conversion. Countless attempts by Oracle executives to clarify what will really happen since then have not completely cleared the air.
Without going into the subject in the depth required to have it make complete sense, I will try to briefly net out why Fusion Applications is a subject that is not worthy of your concern. First, a clarification. Fusion is three things – a technical architectural blueprint that Oracle is following (and that seems to be working out), a body of Oracle middleware products that are well respected and established, and a still under development set of new applications. The discussion below applies only to these Fusion Applications.
Fusion Applications were scheduled to start arriving in 2008. They didn’t. No one seemed to notice or care and Oracle management quietly adopted a policy of making minimal use of the F word. For example, Charles Phillips in his recent keynote at Collaborate confined himself to one brief reference to Fusion Middleware. This was the only time the F word crossed his lips. By not mentioning Fusion out loud Oracle could be preparing us for the introduction of a new brand name. Marketing people love to rename things, especially when the current name develops unwanted connotations.
Ironically, the original grand vision behind Fusion is a good one that is actually working surprisingly well in practice. One characteristic of big ideas is that time has a way of altering them in unpredictable ways. In the case of Fusion, the big change has been the replacement of the application leg of the stool with a better idea. Oracle introduced the nuanced concept of Applications Unlimited to explain it. In overly simplistic terms, the notion is that Oracle’s customers can keep using whatever application suite they have (eBusiness Suite, JDE or PeopleSoft) and slowly add capability and functionality through a growing list of add-on applications. Oracle Transportation Manager, based on the acquisition of G-Log is a good example.
Instead of continuing to call the technological standards that glue together old applications and new functionality Fusion Architecture, Oracle has introduced another challenging term: Application Integration Architecture or AIA. By doing so Oracle has indirectly admitted that the original Fusion strategy has changed in an important way. Rather than just say that a better idea came along, Oracle is finessing the point.
A project lives on within Oracle to build Fusion Applications. Instinct tells us that its priority inside Oracle dropped significantly after John Wookie left in 2008. He was the executive responsible for applications when the original Fusion Application concept emerged. Wookie was replaced by Ed Abbo, a senior executive that came to Oracle as part of the Siebel acquisition. Abbo left Oracle in mid-2009 and was not replaced. Instead, rising star Thomas Kurian now controls all Oracle product development including applications. Under Kurian we expect Oracle’s acquired applications to evolve through the injection of Fusion technology rather than via replacement.
During 2010 Oracle is likely to complete field-testing of at least a few Fusion Application modules. An announcement of general availability will then follow. Relatively little is likely to be invested in marketing in support of it.
The net of our reading of the tea leafs is that Fusion Applications has morphed into more of a research effort than a serious attempt to invent a new ERP suite that will massively replace existing applications. The main reason is more technological than political.
The key technology behind Fusion Architecture is Service Oriented Architectures (SOA) – a sophisticated way to build software out of reusable building blocks. As Oracle started to build Fusion Applications it dawned on them that these building blocks could also be incorporated into existing applications. AIA was therefore created as the mechanism for making this happen. If most Oracle customers can get the main benefits of Fusion without a painful conversion, what is the incentive to do so?
A future posting will explain why we believe that only a modest number organizations will buy Fusion Applications in their pure form in the next few years. In the meantime, you will have to trust me and spend whatever time you allocate to worrying (for me its usually 3-4AM) thinking about more important things.
Please, keep those comments, questions and opposing opinions coming!
The JD Edwards Advisor 
September 26, 2009 at 12:35 am
I have been following Oracle ever since it acquired JDE. I too have a feeling that Oracle has realized over a period of time that why re-invent the wheel. Instead build a technology that can allow disparate applications to be integrated seamlessly and that technology is named Application Integration Architecture and the product is named Fusion middleware. Fusion middleware will become the platform for integrating the disparate application and that will allow customers to keep using the application that they own and on top of it keep plugging-in the products that Oracle sells you (which it acquired) to add value to the business. If Fusion makes the integration painless then the SOA principle is well served.
Gautam
September 28, 2009 at 5:39 am
I generally find that when someone says “painless” when managing systems, they’ve never had to manage the whole system. The advantage that legacy systems, such as JDE World, brought to us was a common architecture. Applications fit easily, worked similarly. Training and use were easier to implement and maintain. Many of us used that same achitecture in our custom code.
The software followed a single, bullet proof technology that was inexpensive to staff.
Now Oracle wants us to cobble together a bunch of “disparate” applications, and call it a system. Kind of like giving you a choice of automobiles using parts from all of the cars around the world. And when the part from Yogo gets upgraded, how does the “system” deal with that? Oracle certainly isn’t concerned.
Some companies will be able to maintain the staffs needed to run these Fusion systems, but there are a heck of a lot of SMBs that that will look elsewhere for future solutions
Michael Caldwell