Oracle Further Orchestrates Its SOA Forays
Part Six: Weaknesses and User Recommendations
Oracle Corporation (NASDAQ: ORCL) has a stalwart application server and database. Its database is a major platform within the SAP and PeopleSoft install base and its back-office applications are also well respected in certain vertical markets. Moreover, Oracle is enjoying a 57 percent increase in application sales in its most recent quarter. Yet despite these accomplishments, its applications business is still behind the market leader, SAP. Even the PeopleSoft addition and the impressive Oracle E-Business Suite 11i.10 release will not likely help Oracle leapfrog over the competition. While Oracle E-Business Suite is the best-attuned offering in terms of pricing, vertical extensions, customizability, professional service approach, etc. it primarily appeals to the needs of large, Oracle-religious enterprises, or to brand new sites. The real "magic bullet" to attract smaller enterprises or enterprises with a bundle of disparate technologies and partners has yet to be produced.
Many of Oracle's attempts to tackle the small to medium business (SMB) market (e.g., Fast Forward, Special Edition, etc.) have merely focused changes around a prepackaged, often hosted product with fixed pricing or competitive pricing due to Linux' low hardware and support costs. However, these do not typically include some horizontal functionality like customer relationship management (CRM), service response management (SRM), or product lifecycle management (PLM), let alone vertical industry extensions. Oracle has recently announced two more offerings dedicated to the SMB market on the platform side: Oracle Database Standard Edition One (already shipping) and Oracle Application Server Standard Edition One (anticipated shipping in early 2005).
Questions about the product quality in the early versions of 11i have played a part in initial lethargic sales of Oracle applications. Namely, Oracle's suite of applications, which, up until version 11i (released in 1999) was, in its most stable form, text-based and dumb-terminal style. Oracle made efforts in the mid 1990s to bring its applications to the Web browser, but these releases had repeatedly been buggy, difficult to use, and often failed to match the feature and functionality set of its text- and client/server-based brethren. This has been mitigated with new releases (now reaching double digits), but a bitter taste and skepticism remains among some users.
Oracle needs to make a dramatic change to increase sales where applications play a crucial role. Databases and application servers are both very competitive and in danger of commoditization. This is not only due to assaults by IBM or Microsoft, but also from the open-source likes of Jboss and mySQL. However, Oracle certainly understands the threat that JBoss or MySQL represents and acknowledges them as competitors. To that end, Oracle can remain competitive from a technical, ease-of-use, and at a feature/function level. The vendor is also making sure that it is easy to migrate from these products to the Oracle stack as the size of customer implementations increases.
Still, the professional services and know-how rich application business has long been wallowing in the shadow of Oracle's two favored "children" which seem to be getting most of the vendor's recent attention. To be fair, the release of 11i.10 should prove the vendor's seriousness about the applications suite. Oracle's recent marketing budget for applications has grown and the vendor has increased its applications marketing headcount. Additionally, 11i.10 was a key message during the recent Oracle OpenWorld user conference in San Francisco, California (US) which has over 20,000 attendees. These events, however, have been overshadowed by Oracle's lengthy bid for PeopleSoft. Nonetheless, considering that the vendor has just paid over $10 billion (US) for an applications company should speak volumes how serious it has become about the applications business.
This is Part Six of a six-part note.
Part One contained the event summary and began the market impact.
Part Two discussed strategy.
Part Three covered strategy shifts.
Part Four examined SOA and Web services. Part Five analyzed the Collaxa acquisition.
The PeopleSoft Factor
Drawing major attention from its executives and the market, Oracle's zealous pursuit of PeopleSoft has also overshadowed Oracle E-Business Suite's marketing. The irony is that SAP, Microsoft, and a slew of other stable, tier two enterprise applications providers (e.g., SSA Global, Infor, Intentia, QAD, Epicor, IFS, etc.) will likely benefit from Oracle and PeopleSoft's distraction with the merger saga. Interestingly, while PeopleSoft's business (new sales) has been tainted by uncertainty, Oracle has suffered damage on the public opinion front. However, now that the former fierce competitors have merged, they can finally concentrate on integrating products and building a new generation of software.
For some, it may have been amazing to see PeopleSoft's protracted resilience to Oracle, which was largely based on the populist message of customer care (despite hefty payoffs and golden parachutes for its former executives). This especially considers that increased profit margins, market capitalization, and shares value promised by Oracle resonate, at least in theory, with PeopleSoft's shareholders. On the other hand, many will have gotten the idea that Oracle's interest in PeopleSoft stems from Oracle's applications functional inferiority, which is far from the truth, at least in terms of both products' capabilities on paper.
Oracle will realize with a heavy heart, that the vast majority of real-world IT departments are a concoction of all sorts of enterprise applications—trading exchanges, SCM, e-collaboration with business partners, PLM, and CRM. These and a number of e-business components require disparate systems to work together. Consequently, not many companies will adopt such a broad solution platform solely from Oracle. Rather they will opt for only those functionally strong components that readily integrate into other legacy solutions. Therefore, time only will tell whether Oracle's vocal endorsement of open technologies such as Customer Data Hub, J2EE, and BPEL will allow customers adopt solutions that fit their needs and which can quickly integrate with their existing infrastructure. But one thing is certain—more Collaxa-like moves should help Oracle become truly open and amenable to playing with others. This is more so than the attempt to absorb the unwieldy mix of PeopleSoft's technologies, many of which Oracle is not only unfamiliar, but of which Oracle likes to hate.
The market should favorably regard Oracle's new mindset and its new moves to placate customers, since Oracle combines comprehensive functionality, updated technology, and greatly improved product quality and usability. Larger enterprises seeking broader e-business capabilities should evaluate Oracle if they feel comfortable with Oracle's one-stop-shop offering and if Oracle has a good track record in their industry vertical. Oracle users should benefit from an integrated database, development tool, and applications server. All of these have been recently upgraded, especially for users that appreciate a single data-model, that runs centrally, and that utilizes grid computing. Enterprises that favor a multivendor approach should still evaluate Oracle if the functional fit is good, but they will have to reckon with a challenging integration project. Users of the former Collaxa product that is embedded within non-Oracle application servers may want to reevaluate their options, although it is very unlikely that Oracle will stop supporting a product that has become an integral part of the Oracle portfolio.
Existing Oracle users should consider Oracle BPEL Process Manager in conjunction with other elements of the broad Oracle 10g platform as a step toward their SOA and BPM initiatives. They should keep in mind that these will have to be bundled with additional resources to training staff in process design and architecture. As enterprises start building dozens of Web services, or create an entire SOA blueprint from scratch, then Web services management and orchestration functionality becomes not only recommendable but essential. To that end, OracleBPEL Process Manager is totally integrated with the application server suite in Oracle Application Server 10g R2. However, caution should be exercised when deploying Oracle applications and platform components whose "tires have not been kicked" in live conditions. Users should leverage the forthcoming upgrade times to evaluate newly released modules and compare it with other products. They should weigh whether the intrinsic integration is more worthwhile than the possible limitation of functional scope and maturity. Also, any new contracts should be well scrutinized to ensure that it is clear and explicit as to preempt any future contract revisions, grievances, and misunderstandings.
On a more general note, although the widespread acceptance of Web services inter-enterprise implementations will not happen any time soon, the involvement of major players should prompt large, global enterprises to start learning the new protocols, standards, and technologies to grasp the potential business advantage. They should learn how developers will leverage Web services, SOA, and BPM; what their ongoing needs are; and what intricacies may arise with the use of these services and systems, such as cultural and standards issues. For casual or power users of desktop business applications, the reason for converting to SOA should be fairly transparent. However, this is may not be the case with IT staffers though. Such a move will represent a significant reworking of the IT infrastructure that is typically a complex mishmash of disparate technologies.
While SOA and Web services may make integration easier through some imposed interoperability, they are not a panacea. They will not eliminate the need for application integration via adapters, connectors etc. Also, although they may provide new business opportunities and create some dynamism and efficiency, these services are not going to transform businesses on their own. They are only a piece of new technology. However, even if large organizations are the first to dabble with deploying Web services, their impact will also felt by companies that supply products and services to consumers, regardless of their size. Businesses can already create and use Web services that can be reused by other applications, such as services to authorize credit card or to authenticate a person's identity while logging onto several systems. Yet, to fully benefit from Web services and SOA, companies should carefully and painstakingly reexamine their business processes and "best" practices to look for the efficiencies a revamped infrastructure could bring.
The starting point for building an SOA blueprint is to identify and create Web services around common business reference objects for the entire organization. This will be largely dependent on the organizational strategic alignment and the industry. While many companies will attempt building their own SOA blueprint, others might be motivated by more complex, cross-company driven SOA blueprints, such as the one already initiated by the Middleware Company.
Likewise when comparing public and private Internet exchanges, Web services seem to have more potential within a trusted environment of business partners. Hence, in addition whether BPEL will be the prevailing standard, there is the question of whether the enterprises will be willing to share business process models with each other. Organizations evaluating Web services and SOA may benefit from following the pertinent consortia activities. Those that have already leveraged Web services may benefit from joining it so as to share the experiences with their peers and to make sure that the consortium focuses on their business issues. However, as the consortia cannot impose much authority on vendors and as it is not performing compliance testing at this stage, users should question vendors directly on standards compliance.
SOA has the promise of interoperability in an increasingly global and heterogeneous business world. It promotes loosely-coupled architecture and non-intrusive reuse of software components, which should do away with vendor dependency for enterprise applications. It should also allow these applications to communicate in near real-time. Before it can all work, however, the likes of SAP and Oracle, must first open up and redesign hundreds of application functions as services. This is a multi-year project that it is, at best, only halfway completed. For customers who have customized these product instances and added additional custom functions and third-party programs, it will be similarly difficult.
Before customers make any attempt at choosing products or product suites for EAI, middleware, Web application servers or other software solutions requiring seamless interoperability, customers must understand the different approaches used by J2EE and .NET. For a more complete discussion of this subject, see Understand J2EE And .NET Environments Before You Choose. While one of the main goals of Web services was to make the platform choice less important, that reality is still a long way off, given hardly anyone can simply rip out the entire infrastructure and start afresh. Despite anyone's platform preference and the roster of programmers with particular skill sets, it is prudent to gather as much information as possible from both camps, as both will have their pros and cons.
Although competition typically results in both camps keeping each other on their toes to be more creative, it does not help users and prospects. Users should question vendors closely on which approach they have (or will be) taking in their current and future releases, and why. Once the choice is made, it will be difficult, although not quite impossible, to switch or abridge. Since application integration efforts are costly, complex and time-consuming, the decision may come back to haunt you if you do not choose wisely. Users must recognize that making a choice for an application server should encompass the entire stack (portal, personalization, directory, etc.).
Niche Web services and BPM vendors should be considered through a tactical mindset and with reasonably quick and justifiable feedback. In general, the market should stay very close to commonly accepted standards, and beware of any vendor that is inclined to create dependence on its proprietary technology, as it leads to unjustifiable price increases, and declining openness in the future.