Government // Enterprise Architecture
Commentary
5/31/2011
11:53 AM
Josh Greenbaum
Josh Greenbaum
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

SAP And Sybase: The Synergy Begins

The two companies appear to be on track to become a cohesive strategic unit, now it's time to execute on that potential.

Following a grueling three days at SAP's Sapphire user conference, a few lucky analysts got to travel to New York and spend a day and a half with an even luckier set of analysts (you could tell who they were because their brains were still functioning), listening to presentations about how well the combined companies are doing, and where they plan to go in the coming years. Where SAP plus Sybase is going can be summed up as follows: The combination of Sybase database and mobile technology has found a perfect home at SAP, and SAP’s yearnings for a fast track to one billion users may have found its perfect home in Sybase. The rest, as they say, is in the execution.

The solidity of the two product lines that Sybase brings to the table is augmented by a strong presence in some key markets that SAP can make tremendous use of. Financial services is the strongest, and despite the tribulations of recent years, this is a sector that knows how to spend on IT. Sybase’s mobility technology promises to let SAP expand in other significant markets as well. More on this in a moment.

One of the more intriguing aspects of the new synergy is the potential for Sybase’s ASE database to unseat Oracle as the DBMS of choice in the SAP market. The announcement that ASE had been certified for SAP was made at Sapphire, and I had a chance to follow-up with the Sybase team in New York on some of the details.

One of the problems with the ASE for SAP strategy--and any rip and replace strategy--is that technological certification is only the beginning and, in fact, represents the easiest and therefore least important of the issues at hand. Rip and replace has always been an interesting theoretical possibility that all too often falls apart in the face of reality: Assuming the technical barriers are overcome, there are still significant economic, cultural, psychological, and contractual barriers to contend with before the theory can become reality. For any company thinking of such a strategy for their Oracle DBMS, all four factors are vigorously at play.

First, SAP/Sybase has to build a strong TCO case for ASE. Sybase thinks there’s a case for making one, but until they do so the theoretical TCO advantage will probably be too theoretical for most CIOs to take action. That TCO case also has to be able to overcome the psychological inertia that looms large in any complex strategic shift: As with many high-priced IT buying decisions, the role of pure logic is usually overemphasized. Making a major DBMS shift, even if it looks good on paper, can and should be a scary prospect for any company. And fixing what ain’t broke should always be viewed through a skeptical lens. Reassuring the decision-makers that rip and replace is a really really good idea and will need to be made really really carefully, or the will to shift valuable resources, political capital, and peace of mind to a rip and replace project will go absolutely nowhere.

Additionally, rip and replace strategies will have to deal with two powerful forces arrayed in opposition. The Oracle world is aided and abetted in the IT department by armies of well-paid, and relatively powerful Oracle DBAs, who will clearly play the role of fifth column against any effort to unseat the Oracle DBMS. And riding in on the vanguard will be Oracle’s lawyers, who won’t let these customers off easy if they have anything to do with it. There's a famous industry trick hidden in contractual minutia that could be leveraged against the customer who wants to rip and replace: Many volume license discounts have triggers that jack up maintenance fees if pieces of the portfolio are decommissioned by the customer. I’ve seen IBM do this to its DB2 customers, and I would assume that Oracle would do the same if it could. The operative word is if: As many, if not most, of the SAP customers who run Oracle actually bought their license through SAP, it may be easy enough to move these customers to Sybase. We’ll have to see: regardless of how it eventually sorts out, I’m pretty sure that Oracle’s lawyers will have their say, if not the final word, on how these rip and replace projects will go.

Sybase also has to worry that it may face a similar rip and replace onslaught against its database products, for which Sun hardware represents the number one platform. Sybase may be additionally protected by the differences between how SAP works with relational database and how ASE-based apps work with ASE. SAP basically treats the underlying database more like a data store than a full-fledged RDMS, and therefore doesn’t take advantage of many of the individual bells and whistles in the many databases that it supports. This means that, while it may be easy to move an SAP application from one database to another, in many cases it will be significantly non-trivial to move many of the high-end Sybase apps running on Sun to an Oracle DBMS. Those apps, most of them custom-built, not packaged, are deeply optimized for the database they run on. Shifting that optimization layer to Sybase would be possible, but Oracle would have to come up with a helluva better economic case for such a switch than I think it possible.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 24, 2014
Start improving branch office support by tapping public and private cloud resources to boost performance, increase worker productivity, and cut costs.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.