on 2011 Jun 29 2:53 AM
Why is it that every day, the front blog page here at SDN reminds me more and more of that old Billy Joel song?
You know the one I mean - "It's still rock and roll to me":
What's the matter with the clothes I'm wearing?
"Can't you tell that your tie's too wide?"
Maybe I should buy some old tab collars?
"Welcome back to the age of jive.
Where have you been hidin' out lately, honey?
You can't dress trashy till you spend a lot of money."
Everybody's talkin' 'bout the new sound
Funny, but it's still rock and roll to me
What's the matter with the car I'm driving?
"Can't you tell that it's out of style?"
Should I get a set of while wall tires?
"Are you gonna cruise the miracle mile?
Nowadays you can't be too sentimental
Your best bet's a true baby blue Continental."
Hot funk, cool punk, even if it's old junk
It's still rock and roll to me
Oh, it doesn't matter what they say in the papers
'Cause it's always been the same old scene.
There's a new band in town
But you can't get the sound from a story in a magazine...
Aimed at your average teen
How about a pair of pink sidewinders
And a bright orange pair of pants?
"You could really be a Beau Brummel baby
If you just give it half a chance.
Don't waste your money on a new set of speakers,
You get more mileage from a cheap pair of sneakers."
Next phase, new wave, dance craze, anyways
It's still rock and roll to me
What's the matter with the crowd I'm seeing?
"Don't you know that they're out of touch?"
Should I try to be a straight `A' student?
"If you are then you think too much.
Don't you know about the new fashion honey?
All you need are looks and a whole lotta money."
It's the next phase, new wave, dance craze, anyways
It's still rock and roll to me
Everybody's talkin' 'bout the new sound
Funny, but it's still rock and roll to me
http://www.lyricsdepot.com/billy-joel/its-still-rock-and-roll-to-me.html
I'm afraid that for me and maybe a few others who do SAP for a livin:
It's still data-processin' to me.
But we're gettin fewer and fewer every day.
Oh well, I guess it's true what they say:
An old developer never dies .... he just occurs less and less.
Till one day, he just occurs 0 . . .
Request clarification before answering.
> Till one day, he just occurs 0 . . .
I'm afraid "occurs 0" has seen its days, welcome back David!
~Suresh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Suresh ! Good to see your byline !
Yes - "occurs 0" has seen its day ... EXCEPT in all the SAP code that SAP won't spend the money to change because all its money is being spent on trying to "keep up with the Joneses" regarding all the new bells and whistles that the market is trying to sell.
Take a look at this blog post:
/people/david.halitsky/blog/2011/06/24/and-now-as-a-public-dis-service-permit-me-to-introduce-a-pseudo-bapi-for-f-32-clearing-wwo-residuals
EVERY SINGLE ONE of the SAP critical SAP itabs used in SAPMF05A form FCODE_BEARBEITUNG is declared "occurs 0".
I mean EVERY SINGLE ONE.
That's why I posted this thread here about "it's still data-processing to me".
How can we ever convince SAP that at least part of its core-business is STILL old-fashioned data processing involving mundane processes like clearing bills against payments, and that therefore ....
for every 10M euro that SAP spends on the lastest bells and whistles, it should spend perhaps 500K euro on updating its CORE BUSINESS PROCESSES.
Particularly since (as I've said many times before), these core business processes must eventually be updated if SAP is really serious about doing its part to bring about THE SOA RAPTURE by its decoupling core business processes from its own transactional view of the world.
Best as always
djh
Edited by: David Halitsky on Jun 29, 2011 4:56 PM
David,
I think a lot of us are more concerned about 2015 in traditional ERP world when mainstream maintenance ends for most current on-premise business suite solutions according to the PAM.
There is even a cult of us who agree with this blog:
/people/sergio.ferrari2/blog/2010/06/25/the-sap-prophecy-of-2015
So the new question is whether ECC 7.0 if ever released will deliver the SOA rapture?
Take care,
Stephen
Hey there -
Don't know the answer to your question, but glad you appreciated the joke. Me and you are like members of a good jazz group - sometimes I lay down the theme and you riff on it, and sometimes you lay down the theme and I riff on it.
Chris Solomon was like that too - he could riff the hell out of one of my themes. Although he was a little shy about layin 'em down himself.
Anyway, I got a question for you about license fee vs maintenance.
Is it possible for a customer to pay SAP just a license fee for a release (4.6c/7 or 5 or 6) without paying any maintenance at all?
Or do you have to pay for some maintenance on top of the license fee?
If it's possible to just pay SAP the license fee then maybe the answer to your "rapture" question might be "no".
Cause the "bad customers" could just keep on payin the license fee for their current release and not care about what ECC 7 does or doesn't bring.
And that would run counter to all accounts of what happens when a "Rapture" comes ... all those "bad customers" are supposed to be thrown into some kind of hell of their own making.
Which I guess in this context would be something like being forced to switch to Larry's E-Business suite ...
Best
djh
Edited by: David Halitsky on Jun 30, 2011 2:46 AM
David,
Well I always understood that license fees were a one time thing and maintenance fees were the gravy that makes shareholder's happy(super high margins, steady stream).
So depending on your license terms, I think you can drop maintenance fees, but lose all access to new versions, support, notes, etc. I really never understood how 3rd party support worked in terms of bug fixes, are those customer specific patches etc? Personally I never understood how cloud solutions are "cheaper", except that you have less staff and hopefully cheaper subscription than your license+maintenance combined and no hardware costs. You also have to assume you can live with less customization of the application, because you don't have "full control".
Funny you mention Chris Solomon, last year at teched Vegas I told him he always disappears when he sees me and then shows back up 15 minutes later. What you don't realize in that 15 minutes he has managed to greet every single attendee of techend within 100 foot radius of where I'm standing (well maybe not that many folks). Chris definitely can riff on these topics also.
In terms of jazz rifts it's easy to start discussing these big topics which you bring up. Vijay from IBM and myself can also "jam" when it comes to CRM related topics.
In terms of those customers well I think "ring of fire/lake of fire" will be the case. Seriously though if your systems still work and they ain't broke, then nobody will probably notice it.
Take care,
Stephen
Hi Stephen -
Well HANA (what you called a a do-it-faster" technology in a different CC post) may not be troubled by the customization issue you mention:
You also have to assume you can live with less customization of the application, because you don't have "full control".
Because when Vertica first developed Stonebraker's C-store concept into the technology that underlies HANA (see my blog here /people/david.halitsky/blog/2011/06/30/why-saps-hana-and-not-its-natural-competitor ), it was understood by all parties concerned that C-store only works on extremely static (non-volatile) data of the type used by BW/BI.
The reason for this is that determination and computation of the relevant columns is where all the overhead is, and this overhead gets too high if the data gets volatile.
So, inasmuch as HANA (or the HP/Vertica appliance) is going to be used for non-volatile BI/BW applications, customization may not be as much of an issue as it is in volatile OLTP or even OLAP applications. Because presumably, the customer knows what the relevant columns are going to be, and they're going to rarely change unless the business model changes drastically.
(This is kind of related to the point Jon Wilson was making in response to my blog post.)
Best
djh
David,
You assume most folks actually get concerned on how open SQL gets translated into real "SQL" and thus want to control that aspect. By control I mean the whole I need the transaction to save/validate in an illogical manner only possible by system modification that we all assume we need is the level of control people want.
The ideal cloud model is that business folks can specified which additional fields and parts of the process they want to use, but can't majorly change the overal process. In other words it's like how Starbucks reduced the menu displayed to a suggested set of choices, but in our case the previous choices are no longer available. Unfortuantely for most SAP Customers, and consultants there has never been a vanilla standard process that has been impossible to implement with modified system.
I am hoping the coffee reference keeps our friends who say these conversations might be too serious for this forum, happy. I just think it's somewhat funny that I'm some how involved in those complaints when I have actually had Screaming Monkey's at SAP Inside Track St. Louis 2010, Teched 2010, and SAPPHIRE NOW 2011.
Take care,
Stephen
I see your point, Stephen. but for me there is memory and history, both of which make the victory of HANA over SQL very sweet, and more important (emotionally and personally) than the other matters you bring up.
In particular, I am old enough to remember when truly great US databases with great query languages went down the tubes because they weren't "relational" and didn't use SQL as their native language.
I also watched as the SQL delusion killed the great company SoftwareAG and its great database ADABAS.
So for a relative youngster like Danny Rohde to post what he posted a few days ago - that HANA finally frees SAP from public interface protocols like SQL - is sweet, sweet indeed.
Mindless adherence to SQL and " relational databases" was a form of mass delusion from which the industry is now just starting to recover. The only good properties of "relational" databases were just common-sense principles that had been around for years and used by anyone interested in good data. And the only good properties of SQL were properties of several much better query languages that preceded it.
Best
djh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.