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+ Sybase is going can be summed up in the following manner: 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 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 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 is 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 is 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.
On to the mobility opportunity. The good news is that Sybase is relatively strong in the high-visibility sectors of mobility – cell phones and tablets. The even better news is that there are signs that Sybase understands the mobility opportunity outside these markets, in particular those sectors, such as health care, engineering and construction, rail transportation, and other industries where very expensive assets come with wheels and have a tendency to end up in places where they either can’t be found or are far from a wired grid.
These industries have a huge interest in managing mobile assets in ways very similar to those in the cellphone and tablet world, with an interesting twist: Phones and tablets have a few sensors that, when added to more traditional CSR data, make for an interestingly large data stream that need to be managed by Sybase’s SUP mobile platform and its newly christened ESP complex event processing and management platform. But their data stream is miniscule to what’s coming out of much more sensor-rich, and therefore data-rich environments. Embedded sensors can send back not just telemetry data, but temperature, humidity, chemical composition, and a host of other valuable data points from the kinds of mobile assets in use in industrial settings. Connect those data to the back-end ERP system and a lot of exciting new, analytically-rich apps can be built. It’s an amazing opportunity that both Sybase CEO John Chen and SAP co-CEO Jim Snabe get.
And once they add this extended mobility scenario to the already rich cellphone and tablet opportunity, the billion user mark starts looking relatively easy. Cellphones and tablets touch every consumer on the planet, something that should help SAP with that billion user target, and extended mobility extends the operational and analytical footprint of SAP into key industries in which SAP already plays much more deeply than ever before.
Which brings us to the one big question still sitting on the table: how does SAP/Sybase monetize these opportunities? SAP clearly wants to sell enterprise-class apps into Sybase’s mobile market, but doing so at a price point that works will be tricky: the price points for consumer cellphone apps may not work for an SAP that is used to more value-based, and therefore much more expensive prices. Chen clearly has some notion of how that pricing should work, but the jury is still out on how to balance the pricing models to ensure that SAP gets what it thinks it deserves and the customers pay what they think they should be paying.
These are good problems to have in the greater scheme of things: what is clear is that the opportunities are there and the two companies are on the right track to become a cohesive strategic unit. Some glitches are bound to surface: Sybase has a set of mobile CRM apps that demo really nicely on an iPAD, so nicely that they might confuse buyers trying to decide what SAP CRM offering would be best for their mobile workforce. The user experience of these mobile apps is so different than Sales On-demand that some convergence would need to take place before they could be deployed to the same sales force. Not such a good problem to have.
But in the end, it’s a good beginning for the newlyweds, considering how recently the nuptials took place. The rest, as I said in the beginning, is in the execution. Stay tuned.