Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Monday, November 29, 2010

Rimini Street to Oracle: don't expect us to roll over

As everyone knows by now, Oracle won a huge ($1.3 billion) judgment in its lawsuit against SAP/TomorrowNow (TN) for copyright infringement. SAP had acquired its now-shuttered TN unit to provide third-party support for some Oracle business applications in hopes of winning those customers over to SAP. SAP is considering an appeal of the jury verdict, the largest ever in a copyright case.

In the meantime, Oracle has a lawsuit pending against another third-party support provider, Rimini Street. At first glance, Rimini Street "looks like" TN in that both are/were providers of third-party support for Oracle applications. Furthermore, Oracle's lawsuit makes similar allegations--some of it appears to have been cut and pasted from its suit against SAP.

So it would be easy to assume that Oracle's hand against Rimini Street has been strengthened by its win against SAP.

Why Rimini Street isn't TomorrowNow

It would be easy, but it would be wrong. Here's why:
  • Admission of liability. Nearly from the start, SAP admitted that something was wrong down at its TN unit. By the time the case went to trial, SAP had basically thrown in the towel, admitting not only that TN had violated Oracle's copyrights but that SAP itself knew about the illegal behavior.

    In contrast, Rimini Street is making no such admissions. It has from the beginning steadfastly rejected all allegations that it is violating or has violated Oracle's IP rights. In several interviews I've conducted with the firm's executives over the past three years, it has claimed to have established clear policies and standards to prevent such misuse and has offered to have Oracle audit its practices. Oracle has refused such offers, choosing instead to file a lawsuit. So much for allowing Rimini Street to compete fairly.

  • Counter-punching. From the start, SAP was playing defense against Oracle's allegations. It never counter-sued or alleged misdeeds on the part of Oracle.

    In constrast, Rimini Street is fighting back. In a statement sent to me by Rimini Street last week, the firm writes, "While SAP chose not to challenge Oracle's allegations of liability, Rimini Street is aggressively challenging Oracle's allegations and prosecuting its own claims against Oracle."

    It goes on, "While SAP chose not to challenge Oracle's allegations, Rimini Street has countersued, accusing Oracle of defamation and using illegal and unfair practices to stifle competition for the lucrative support and maintenance business. Rimini Street intends to stop what it believes are Oracle's illegal actions and is seeking to hold Oracle responsible for its conduct."

    In other words, if Oracle thought Rimini Street would simply roll over, it thought wrong.
I suspect Oracle would like to have these two lawsuits run together in the mind of customers, prospects, and the general public. But, Rimini Street appears determined not to let that happen.

SAP's hands were tied against Oracle

The ironic part of the Oracle v. SAP/TN case is that SAP couldn't mount a vigorous defense without shooting itself (forget about the foot!) in the head. SAP, like Oracle, is addicted to its lucrative maintenance business. It is baffling why SAP chose to acquire TN in the first place, for some tactical advantage in converting a few Oracle customers to SAP? While undermining its whole business model for sustaining revenues from its installed base? What was SAP thinking?

So, when Oracle filed suit against SAP, what was SAP supposed to do--counter-sue Oracle for restraint of trade and unfair competition, and thereby conceding to any large hungry system integrator or competitor (think, IBM or HP) that its own installed base maintenance revenues were ripe for picking? Of course, SAP had to defend itself. But it couldn't defend itself too strongly, lest it wind up giving legal precedent to the third-party support industry. As it turns out, as the case proceeded through discovery, Rimini Street announced it would begin offering third-party support services for SAP's customers in addition to the services it was offering to Oracle customers. So, SAP was stuck between the proverbial rock and a hard place.

Rimini Street has no such baggage. It can and appears to be willing to mount a vigorous defense of its own rights to offer third-party support services, based on the contractual rights of customers to self-maintain their licensed software, while respecting the IP rights of OEM software vendors.

Why Rimini Street's case is important

As Rimini Street stresses in its statement this week, "both Oracle and SAP have acknowledged that third-party support is legal." I covered this point back in 2008 in a post entitled, Legal basis for third-party ERP support industry. In a little-noticed letter filed by SAP as part of pretrial discovery, TomorrowNow strongly asserted its legal right to offer third-party support for PeopleSoft customers, and PeopleSoft backed down from its claim that such support was illegal. Furthermore, to my knowledge, Oracle has not gone so far as to argue that TN had no right to offer support. Only that it did so by stealing Oracle's IP.

Rimini Street is strongly claiming not to be infringing on Oracle's IP. If it can back up that claim in court, then, in my opinion, a strong legal precedent will be established for the third-party support industry. Furthermore, if Rimini Street is successful in its counter-claim against Oracle, it will strongly restrict the attempts of vendors to prevent customers from seeking third-party support--which, ironically, SAP itself appears to have tried to do in 2009!

Strange, isn't it? SAP was defending itself as a provider of third-party support for Oracle customers, while at the same time apparently trying to prevent its own customers from using third-party support.

So, SAP was fighting Oracle with one hand tied behind its back. As Rimini Street's statement now points out, "Had SAP availed itself of the claims and defenses pleaded by Rimini Street in its case against Oracle, SAP would have placed its own policies and third party revenues in jeopardy. "

So, why is the Rimini Street case important? Because the rights of customers to not be locked into a single source for maintenance and support needs to be preserved. As I've written many times in the past, when you buy a Lexus, you have the right to take that Lexus to any third-party repair shop. Lexus cannot try to stop you or threaten to void your warranty if you do so. If they tried, the US Department of Justice (DoJ) and 50 state attorneys general probably would file suit. Why should the enterprise software industry be any different?

DoJ is reported to be looking into the Oracle/SAP matter. If so, and while it's learning about this industry, it should also take a look at the restraint of trade and antitrust implications of both SAP and Oracle's behavior in attempting to prevent a viable third-party support industry.

Statement from Rimini Street

Here is the full statement from Rimini Street, sent to me last week.
While SAP chose not to challenge Oracle's allegations of liability, Rimini Street is aggressively challenging Oracle's allegations and prosecuting its own claims against Oracle.

We believe the resolution of the Oracle vs. SAP case does not impact Rimini Street’s case against Oracle and does not change anything in the fast-growing third-party support market.

A few key facts:

Both Oracle and SAP have acknowledged that third-party support is legal. Oracle's claims relate to the specific processes and procedures used to provide support for their products. The processes and procedures used by Rimini Street are very different from those used by SAP.

The only substantive similarity between the offerings of SAP/TN and Rimini Street is that they both provide third party support at 50% off the software vendor's annual fees. As clearly articulated in the court documents and the thousands of pages of process documents provided to Oracle by Rimini Street, every other aspect of Rimini Street’s operations is significantly different that the operations of SAP/TN. Oracle knows this to be true.

We believe the magnitude of the damages award is a result of SAP's peculiar decision to concede liability and ultimately not challenge Oracle's claims. It bears noting that SAP, like Oracle, derives many billions of dollars from maintenance and update services to its customers with profit margins not unlike Oracle’s.

SAP’s practices and conduct in their attempts to chill growth of third party maintenance are similar to Oracle’s. Had SAP availed itself of the claims and defenses pleaded by Rimini Street in its case against Oracle, SAP would have placed its own policies and third party revenues in jeopardy. SAP abandoned these claims and defenses at its own peril, as the size of the damages award illustrates. While SAP chose not to challenge Oracle's allegations, Rimini Street intends to stop what it believes are Oracle's illegal anti-competitive actions and will hold Oracle responsible for its actions.

While SAP chose not to challenge Oracle's allegations, Rimini Street has countersued, accusing Oracle of defamation and using illegal and unfair practices to stifle competition for the lucrative support and maintenance business. Rimini Street intends to stop what it believes are Oracle's illegal actions and is seeking to hold Oracle responsible for its conduct.
Update, 1:40 p.m.: Dennis Howlett has a good post on the long-term implications for customers if vendors can get away with squashing the nascent third-party maintenance industry.

Related posts

SAP and third-party maintenance: good for me but not for thee
Legal basis for third-party ERP support industry
Oracle slams Rimini Street with lawsuit over third-party maintenance

by Frank Scavo, 11/29/2010 07:07:00 AM | permalink | e-mail this!

Subscribe!

 Reader Comments:

Frank -

I would have liked to see some mention on the links between TomorrowNow and Rimini Street, e.g., Seth Ravin. Seth is CEO and President (and Founder) of Rimini Street, and was Founder of TomorrowNow and self-described architect of the service. In fact, if you read this detailed interview http://www.cio.com/article/333313/The_Man_Behind_Half_Off_Third_Party_Software_Maintenance, you'll see he says things that imply that Rimini Street is a carbon copy of TomorrowNow - e.g., "Our basic model for TomorrowNow customers is that you're going to get the same kind of savings. What we're offering is on top of what they're used to, which is the vanilla offering that I actually assembled—because it hasn't changed much from what I put together at TomorrowNow several years ago when we were launching the company. So what we provide is extended coverage beyond that, as part of what I built at Rimini Street. ... You can't take the facts away of the history because our histories have run together. There's no way to separate it. ... You cannot take us 100 percent apart and say we have nothing to do with each other."

In his own words ...

Oddly, in his bio http://www.riministreet.com/senior_management_team.htm on the Rimini Street web site, he does not mention that he was founder of TomorrowNow. He alludes to it but never mentions the name TomorrowNow in his bio.

I have yet to see a description of how Rimini Street identifies bugs, creates fixes, tests the fixes, and deploys them to customers. It's hard to imagine that Rimini Street does this with a small staff lacking access to the core product developers and the entirety of the products' source code.

I look forward to hearing how this is done. Everyone should aspire to a more efficient deployment and maintenance of enterprise software, but not if it means IP theft, as SAP confessed to in its case with Oracle.

Thanks, and keep up the great research and analysis!

- Dennis Moore
EnterpriseIrregular.com
 
Thanks, Dennis. I'm sure those quotes you dug out will ultimately be presented by Oracle, if this case ever reaches trial. On the surface, I can see how someone might draw the conclusion that Rimini and TN are birds of a feather.

As I indicated in the main post, I have queried Rimini Street on this point at least twice, maybe three times over the past three years. Each time, Rimini Street has been very clear that they have established strong policies, procedures, and controls to prevent misuse of Oracle's IP. I have not personally audited those controls, however, and can only relay what Rimini has represented to me.

If this case moves forward, I'm sure we'll have a chance to see the kind of detail you are looking for. I hope it does move forward, because as I said, I would like to see a clear model and precedent for doing 3PM properly. That would create a more healthy marketplace for enterprise software, with a more even balance of power between buyers and sellers.
 
I believe third party support/maintenance is here to stay thanks to the steady hand of the DoJ and equivalent government bodies around the globe. Third party providers will get smarter at avoiding IP theft and enterprise vendors will get smarter at controlling access to their IP.

The question is how much market share third parties will hold over time. The percentage will provide a valuable measure of customer dissatisfaction. Enterprise vendors will form their own view on what amount of third party share is tolerable to them - and take pricing and product decisions to influence this.

I don't buy the idea that customers (on third party maintenance) are happy with their mature and stable enterprise solutions. Instead these customers have been stung by the complexity and cost of enterprise solutions and have run for cover. Inside each customer is a large group of managers and an even larger group of staff who are dissatisfied with their dinosaur solution and wonder why it has fallen so far behind the consumer apps they have on the personal smart phone. Yes this isn’t a fair comparison – for various reasons – but it makes the point that there is much room for improvement.

Many of these companies have themselves to blame as much as they do enterprise vendors, but given the situation they now find themselves in, seeking a lower cost model is a wise move - or the only viable move in the short term. Some customers have resorted to no support at all.

So, assuming these customers do in fact want to improve their solution, this begs the question of where do they go from here? Developing on third party support might be a good option for a number of years but in the long run leads to a dead end thanks to the proprietary technology. Instead they must either reconnect with their original vendor or seek out a replacement proprietary vendor, open source vendor, or build their own system using either proprietary or open source technologies.

Personally I think those customers in or seeking third party maintenance are good candidates for an open source solution - because they are willing to deal with the same sort of fragmentation or "fork" issues that come with open source development. For this reason if I were in Rimini Street’s shoes, I would consider acquiring an open source enterprise vendor, or form a strategic alliance with an open source enterprise vendor – and offer a “safe passage” program similar to what SAP tried to do with TomorrowNow.

Going back to the big proprietary enterprise vendors, I think that by increasing openness and interoperability, they will be able to address much of the rot that has set in. They can still control the high ground (platforms and infrastructure) while opening the floodgates for consumer tech to flow into the corporate application landscape.
 
Matthew, I agree with you regarding the factors that make 3PM appealing to customers. I also believe that even in the bulk of customers do not go with 3PM, the fact that they *can* do so puts some much-needed balance of power into the customer/vendor relationship. In other words, it puts some pressure on vendors to improve their quality of service and moderate their pricing.

As you may know, I happen to be an advocate for open source solutions, generally. However, I don't think Rimini Street has any interest, nor should they, in offering any solution. They are a services business pure and simple. There's something to be said in favor of focus.
 
Frank,

I interviewed with Rimini Street 2 years ago when they were planning to start their SAP practice and I asked some tough questions and wanted to see how they can provide support without source code. I wanted to see how Rimini Street identifies bugs, creates fixes, tests the fixes, and deploys them to customers. It's hard to imagine that Rimini Street does this with a small staff lacking access to the core product developers and the entirety of the products' source code.

As I expected the EVP from Loas Angeles had no clue and he danced around the issue. I immediately suspected some thing.

Funny thing was they wanted me to sign a NDA even for an interview which I refused to sign ! EVP not knowing that I had not signed an NDA, called me over the phone for interview and said his business model is confidential and ehnce he wanted the NDA etc. When I said your business model is nothing different than Tomorrow Now business model, he immediately shut up.
 
Hi Jay, two things: first, can you let us know what you do for a living, and what your relationship is with SAP, if any?

Second, is Rimini Street able to provide its services while respecting Oracle's IP rights? That is the subject of Oracle's lawsuit. You indicate you were not able to learn much about Rimini Street's processes without signing an NDA. Well, if this case goes to trial, I suppose you'll get your answer one way or another, right?
 
My company has now spoken to Rimini Street about both PeopleSoft and SAP support. Both times we were never able to feel comfortable about their answers for how they build and source patches. They always said Oracle wouldn't sue them but here we are. What if SAP decides to sue as well? Be interesting to see how it plays out.

Rimini Street told us they will only use our own patches that we are entitled to and they download while we are a paying support customer. They feel if they download for us while on support we have rights in the future to all that material available if we downloaded it before support ended. Our license agreement seemed to say we do have this right but our lawyers said it could be a lot of exposure if we were proven wrong down the road. In two years if Rimini goes "kaput" imagine what will happen to us if we need to go back to Oracle or SAP.
What really worried us the is in the future they will provide NO security updates, NO tools fixes, NO database updates, etc. It seemed the longer we stayed on an old release the more we will end up boxed in due to changing technology, we have all seen what happens when browsers chang. They claim workarounds exist but couldn't/wouldn't share tme with us now If we discover a new issue they create a one of patch just for us, there are no proactive updates available.

We also never felt comfortable knowing there was a chance they could use our downloaded material for another customer they were supporting ala TN. They say they won't but if they did would we be responsible if Oracle/SAP came back to us as the original licensee and we didn't protect the downloaded material?

Support seemed to be pretty good from the checking we did, but they were quite evasive on the SAP side about how many resources they have and if they could really support P1 issues from multiple customers if they occurred at the same time. We didn't think there was a true global support infrastructure that could respond to multiple customers having high priority issues at the same time. They seem to be playing the odds that this won't occur.

In the end it seemed almost all of their customers were using them while preparing to move to another platform or they were in some sort of drastic cost cutting mode. We didn't feel like 50% savings would be enough when you weighed all of the potential exposure and questions about what to do in 3-5 years when we might have to make a change. The ROI seemed ok until you factored in the stuff they didn't want to talk about as their ROI won't look nearly as good as the spreadsheets they send out with your data.

And to the first poster- LinkedIn is great for checking on people and we noticed the same changes to the CEO's biography and past statements about his role at TN. TN was a pretty small company, kind of hard to be out of the loop if you were an executive there.
 
interesting comment
 
Post a Comment
 

Links to this post:


 

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
November 2014
December 2014
Latest postings