Re: {Spam?} RE: Informix Roundup: 26 July 2009
Posted in 2009
Ian Michael Gumby schrieb: > > >> From: chknews@gmx.net > > >> SAP supports every new Informix releases for all SAP products that are >> supported with Informix. These are all ABAP systems up to basis relese >> 6.40. > > Really? Yes. > Is 6.40 the latest release? No -- and I did not assert that. > If this statement is true, then why did all of the SAP customers on IDS > migrate to a different platform? It is /not/ true that 6.40 is the latest release. All of SAP's customers know that 6.40 is the last release that supports Informix. Beyond that, it's a public information. > Sorry but your statement is a bit disingenuous. I'm sorry too. But in another post of this thread you said that you don't use SAP. I assume that you don't know all the facts of SAP's release strategy, including the above said. Then I consider your judgement a bit harsh. > The question isn't that > SAP supports new releases of IDS on existing ports of products, but that > SAP told customers that after release X, they would no longer be > supporting those products on Informix. And nobody denied that. As I said, X = 6.40 (basis). >> > Is this a subtle way to say that they *may* support IDS in the next >> > release? >> >> No. >> >> > Isn't that too late for the existing ISP customers that had to >> > migrate? >> >> *sigh*, yes. >> > > Ah, so now we're getting to the bottom of things. ;-) > >> > Just out of curiosity, if there is an SAP knowledgeable person, of the >> > SAP implementations that went wrong, like Nike for example... How many >> > of those were on Oracle, IDS, DB2, SQLServer? >> >> Well, AFAIK no SAP implementation went wrong because of the chosen >> platform. A "nice" example: http://sapmesideways.blogspot.com/ (worth >> while to read the whole sad story). Besides, I assume that most failed >> projects were on Oracle. But that is for no other reason as the one >> that most SAP customers choose Oracle as their database vensor. >> >> Regards >> Christian > > It wasn't a question of implementations that went wrong because of the > underlying database platform. > It was tracking the implementations that went wrong by database > platform, and then looking at the ratio of problems to number of > customers on that platform. If there had be an implementation project that had failed because of real database issues like architectural issues or bugs, not admin, consultant, hardware or operational issues, I had noticed. At least if Informix, MaxDB or DB2 LUW had been involved. And my colleagues had told me of other database ports. (Not that I did not had to deal with admin, consultant, hardware or operational issues.) Regarding the number of implementation failures by database platform, there are no statistics that are available for all employees or even publicly. In fact there are only very few projects that fail completely. And I deny that there is any connection to the database platform like you tried to draw. > This would give you an apples to apples comparison of issues. Well, no. > I used Nike as an example because Nike claimed that the migration to SAP > was botched, cost Nike 1 billion dollars in lost business/revenue and > they sued SAP and Oracle. (No I don't recall the outcome.) > > Not to pick on Oracle, but it was a very visible and noteworthy example. > > The idea is to say by platform, XXX projects went wrong and it > represents YY% of our customers on that platform. With XXX being a single- or a small double-digit figure, depending on the total number of the platform, and YY less than 1. > These numbers should be known at least by SAP. Only to very few of the ~50000 who make SAP. > As to assigning blame as > to why those projects went bad, its outside the scope of the question. > You could have had Informix, Oracle, IBM or another 3rd party, or SAP > themselves running the project. All sorts of factors, including the > customers themselves could have lead to problems. You say it. And to sum it up: you try to draw a connection between two totally independent entities. Best regards Christian -- Disclaimer: The statements made above are my own statements and don't necessarily reflect those of my employer.