I am getting surprised how Oracle's Application Unlimited (AU) program is getting a bad reputation in the news and blogsphere recently... probably all triggered by the recent Forresterreport that is being widely discussed.
Let's first understand why enterprise software customers switch products:
![]()
Back when Oracle designed AU the pressure on the company was mainly on vendor viability and maintenance. There were no doubts on Oracle's company viability, but the question was, if there would be enough talent left at the acquired companies to maintain viable offerings. On the maintenance side Oracle needed to dispel the concerns that the acquisitions would be stopped in their tracks and customers forced to move over to Oracle's e-Business Suite. There was no TCO pressure on the acquired products and likewise there was no concern on Oracle providing adequate support. The 3rd party support market saw a small boom as some enterprises used the Oracle acquisition to clear house in regards of the enterprise vendor strategy and thus opted for 3rd party support during the transition time as they were off to another vendor.
At the time Oracle also realized, that enterprises only change their vendors if they really, really have to. It's very hard to switch systems and vendors. If you take away the concerns, build the trust and do what you say - enterprises will trust you and stick around. Many nervous Peoplesoft and Siebel customers agreed to wait for one year and see what would happen. Most of them are still with Oracle, as Oracle delivered on the AU promises. Despite all attempts from the competition (remember 'Fusion Confusion') there have not been significant takeaways of customers from Oracle by other vendors.
At first AU was put away as 'typical' Oracle marketing, then Oracle's commitment to keep going at AU was questioned. Ironically now AU gets blamed from preventing Oracle customers to move to Fusion.
But what if Oracle had mandated a hard stop in maintenance for the acquired products? Oracle explicitly countered that with their lifetime support pledge. But let's play it through - a hard end of maintenance would have forced customers to move to Oracle e-Business Suite (a concern that never materialized) or to the new Fusion Apps. We all know what would have happened: Unhappy and angered customers would have headed to the exits. Massive pressure on Oracle's product development teams to deliver as soon as possible. Worries about missing business functionality. Quality compromised. Skilled labor shortage. Etc. Oracle would have deserved bad press for it. But that didn't happen - as we all know.
Instead AU's maintenance strategy is providing customers with more needed business functionality and with that making it harder for the Fusion product development teams to reach functional equivalency. But it would be false for Oracle to even chase that strategy. Bad things happen to enterprise software vendors when they chase functional parity with a previous product line. Just look what happened with Dun&Bradstreet trying to build the same functionality in their new client server products than what they had in their mainframe product (they never made it). Or look at what happened when SAP's product development teams were on the 'death marsh' to provide functional equivalence between old R/2 and new R/3. There was some urgency here - as mainframes became unattractive to operate (see the above TCO argument) - but it cost SAP dearly as product development was looking at past processes and old best practices and the company missed major business trends and whole software categories with CRM, SCM and Purchasing. So Oracle's Fusion development teams are not chasing every piece of functionality that is being used in Oracle e-Business Suite, Peoplesoft, Siebel and JD Edwards products - but instead looking at next generation best practices and the specific exploitation of capabilities of the Fusion technology stack (e.g. collaboration) that will help to differentiate Fusion applications from the AU applications.
![]()
So when will Oracle pull the trigger and force customers to Fusion Applications? I think that will only happen when Oracle is ready - and Oracle will be ready with Fusion Applications when the TCO of running them will be so compelling that customers want to move to Fusion Application by themselves. Though Oracle never makes a public statement in this regards, TCO is baked in the company's DNA. Remember that the original business idea of Oracle was to build a cheaper to operate (TCO) database. And we all know, that Oracle will make the TCO message heard loud and clear (1st page Wall Street Journal - as usual).
But what about the Oracle customers? As long as they get good support, good maintenance and the technology they operate on will not get obsolete - they are in a good spot. They can keep Oracle honest with threatening to move to other vendors or by talking to 3rd party support vendors. This simple system of checks and balances has been working well for customers since 2006. The only risk for customers is, when the customer population on an AU product gets too small for Oracle to be interested in these customers, as support and maintenance gets too expensive.
MyPOV: Oracle's Applications Unlimited strategy has proven to work in a very competitive market place. Kudos to enterprises to wait and let Oracle deliver and gain their trust, kudos to Oracle for delivering on it (so far). Applications Unlimited also allows Oracle to build better Fusion Applications than otherwise possible, the argument to move the existing customers on the acquired products needs to be TCO - and that's a good message for the whole industry.
[Disclosure 1st: I worked at Oracle at the time the AU program was conceived and wasn't totally un-involved - so keep my potential bias here in mind.]
Let's first understand why enterprise software customers switch products:
- Vendor viability
If you are worried about your vendor not making it to the next quarter, you know you have a problem that you better solve soon. The viability of a vendor may also be affected by acquisitions in the market place. It may not even be your vendor being acquired - but their closest competitor maybe snapped up by Oracle or SAP and now they have much deeper pockets, reach etc.
- Technology obsolescence
You saw it coming all the way - the technology you are running your systems on is becoming obsolete - it is no longer supported, can't be maintained etc. Luckily we haven't seen that too much in the last decade, since somehow vendors managed to transition from client server to the internet architecture and from there (somewhat) to the cloud infrastructure.
- Total Cost of Ownership(TCO)
The technology you run you enterprise application on, is still supported, but getting punishingly expensive. Someone in your enterprise maybe 'sleeping at the wheel'. I have seen the fair share of this in action, with eg vendors buying Visual Basic runtime licenses on the grey market to keep their offering afloat. Enterprises collecting database licenses that are no longer sold etc. And TCO has been very real in shaping today's enterprise vendor landscape - as client server turned out to be so much better in TCO than mainframes (IBM will differ) - but that's the reason why Dun&Bradstreet, GEAC, AMS et al are no longer in the enterprise application business.
- Maintenance
Maintenance is partially related to vendor viability but still a key factor on its own. Enterprises pay for maintenance and rightfully expect not only bug fixes but also the further continuation of functionality development. These functional roadmaps are to keep business software close to best practices, regulations etc. If your vendor does not have a credible roadmap, you need to look somewhere else.
- Support
Even with the most seasoned in house team, you rely on the support of your vendor. If the support is not available, not acceptable or too expensive - you may no longer tolerate or be able to afford to use that vendor's system. You may disassociate from your vendor slowly by using cheaper 3rd party support options from the RiminiStreets et al.
Back when Oracle designed AU the pressure on the company was mainly on vendor viability and maintenance. There were no doubts on Oracle's company viability, but the question was, if there would be enough talent left at the acquired companies to maintain viable offerings. On the maintenance side Oracle needed to dispel the concerns that the acquisitions would be stopped in their tracks and customers forced to move over to Oracle's e-Business Suite. There was no TCO pressure on the acquired products and likewise there was no concern on Oracle providing adequate support. The 3rd party support market saw a small boom as some enterprises used the Oracle acquisition to clear house in regards of the enterprise vendor strategy and thus opted for 3rd party support during the transition time as they were off to another vendor.
At the time Oracle also realized, that enterprises only change their vendors if they really, really have to. It's very hard to switch systems and vendors. If you take away the concerns, build the trust and do what you say - enterprises will trust you and stick around. Many nervous Peoplesoft and Siebel customers agreed to wait for one year and see what would happen. Most of them are still with Oracle, as Oracle delivered on the AU promises. Despite all attempts from the competition (remember 'Fusion Confusion') there have not been significant takeaways of customers from Oracle by other vendors.
At first AU was put away as 'typical' Oracle marketing, then Oracle's commitment to keep going at AU was questioned. Ironically now AU gets blamed from preventing Oracle customers to move to Fusion.
 |
| Taken from Oracle's website |
But what if Oracle had mandated a hard stop in maintenance for the acquired products? Oracle explicitly countered that with their lifetime support pledge. But let's play it through - a hard end of maintenance would have forced customers to move to Oracle e-Business Suite (a concern that never materialized) or to the new Fusion Apps. We all know what would have happened: Unhappy and angered customers would have headed to the exits. Massive pressure on Oracle's product development teams to deliver as soon as possible. Worries about missing business functionality. Quality compromised. Skilled labor shortage. Etc. Oracle would have deserved bad press for it. But that didn't happen - as we all know.
Instead AU's maintenance strategy is providing customers with more needed business functionality and with that making it harder for the Fusion product development teams to reach functional equivalency. But it would be false for Oracle to even chase that strategy. Bad things happen to enterprise software vendors when they chase functional parity with a previous product line. Just look what happened with Dun&Bradstreet trying to build the same functionality in their new client server products than what they had in their mainframe product (they never made it). Or look at what happened when SAP's product development teams were on the 'death marsh' to provide functional equivalence between old R/2 and new R/3. There was some urgency here - as mainframes became unattractive to operate (see the above TCO argument) - but it cost SAP dearly as product development was looking at past processes and old best practices and the company missed major business trends and whole software categories with CRM, SCM and Purchasing. So Oracle's Fusion development teams are not chasing every piece of functionality that is being used in Oracle e-Business Suite, Peoplesoft, Siebel and JD Edwards products - but instead looking at next generation best practices and the specific exploitation of capabilities of the Fusion technology stack (e.g. collaboration) that will help to differentiate Fusion applications from the AU applications.
So when will Oracle pull the trigger and force customers to Fusion Applications? I think that will only happen when Oracle is ready - and Oracle will be ready with Fusion Applications when the TCO of running them will be so compelling that customers want to move to Fusion Application by themselves. Though Oracle never makes a public statement in this regards, TCO is baked in the company's DNA. Remember that the original business idea of Oracle was to build a cheaper to operate (TCO) database. And we all know, that Oracle will make the TCO message heard loud and clear (1st page Wall Street Journal - as usual).
But what about the Oracle customers? As long as they get good support, good maintenance and the technology they operate on will not get obsolete - they are in a good spot. They can keep Oracle honest with threatening to move to other vendors or by talking to 3rd party support vendors. This simple system of checks and balances has been working well for customers since 2006. The only risk for customers is, when the customer population on an AU product gets too small for Oracle to be interested in these customers, as support and maintenance gets too expensive.
MyPOV: Oracle's Applications Unlimited strategy has proven to work in a very competitive market place. Kudos to enterprises to wait and let Oracle deliver and gain their trust, kudos to Oracle for delivering on it (so far). Applications Unlimited also allows Oracle to build better Fusion Applications than otherwise possible, the argument to move the existing customers on the acquired products needs to be TCO - and that's a good message for the whole industry.