In actuality, Oracle’s announcement was hardly just another exercise in altruism. Over the past year or more, Oracle’s president Charles Phillips has been sounding conciliatory words to the client base about protecting investments, and not requiring forced migrations. But there are cold hard business realities that are driving Oracle to make more nice with its installed base.
The first fact of life is that, when you have a large enough customer base, you’ll attract more flies with honey and, more importantly, that maintenance can become quite a lucrative business.
Mike Greenough, who brought SSA Global back from the dead prior to its sale to Infor, made that point quite forcefully when faced with a similar agglomeration of product lines. Until then, conventional wisdom was that maintaining multiple incompatible lines would drain the business. But once you have accumulated such a large chunk of the market and so many product lines, the costs of convergence get far outweighed by the revenue potential of simply maintaining and gradually enhancing them.
Anyway, with Y2K over, customers are hardly in the mood to rip and replace once more.
Sure, Oracle could make a lot more money if its customer base (grown much fatter through acquisition) would migrate to some future Fusion application. But even were Oracle to continue pressing full steam ahead with Fusion apps, that product is so many years away that it would face pressures from two constituencies: shareholders that demand continued quarterly growth, and a huge installed base that demands better functionality and interoperability now.
That’s why SOA has become for most corporate customers more than a technology buzzword. And that’s also why Oracle’s so-called Project X might try to accomplish what has so far eluded cross industry organizations like the Open Applications Group (OAG): defining a set of common business objects so one enterprise system could exchange its customer object or order-to-cash process with another.
The dilemma with standards is that, the higher you go up the stack, the more contentious standards efforts become. At that point, that’s where software vendors contend their value add kicks in. Consequently, it is far easier to define headers for web service descriptions than it is to define a business process.
So, on this go-round, why should Oracle be able to pick up where OAG has left off? We have enough of an installed footprint that this could become a de facto standard, explained Paco Aubrejuan, Oracle’s vice president of application strategy.
If Oracle is smart, Project X could generate an annuity business. At the end of the day, there is practically no limit to the number of business process permutations that could in some way be loosely coupled with standard piece parts. SAP is already several years down this road with xApps. And of course, given its large footprint, and the fact that from necessity Oracle has to make nice with integrators and third parties, this has the makings of a prospective third party ecosystem.
But while Project X offers prospects of faster deliverables than something like Fusion applications, it’s for now very much a work in process. It’s not simply that Oracle is only just starting to roll out a couple of what will be dozens of process integrations. It’s that the technology base is still in flux.
Yes, Oracle has committed to using BPEL (Business Process Execution Language), a web services standard for loosely chaining together multiple services, but there are other proposals before Oasis and other standards bodies like OMG, such as the Service Component Architecture (SCA), Service Data Objects, and Business Process Modeling Notation (BPMN), that could play far more pivotal roles in defining underlying infrastructure on which Project X will likely depend.
