Regarding ABAP getting obsolete

Read only

2,144

SAP Managed Tags
SAP Community

Iam hearing the rumors of JAVA developers dominating the ABAPers

any comments.

rgrds

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (8)

> Iam hearing the rumors of JAVA developers dominating the ABAPers

> any comments.

> rgrds

Well. I wonder how that is going on. I'm working for product management in Walldorf, (building 3 for those who know the map). I'm located on level 2. Most of the NetWeaver ABAP development is on level 1 in that same building, while NetWeaver Java sits on level 3 (besides those parts that work in other countries). Due to the nature of their work, both groups care most for their respective servers and don't waste their time by trying to dominate each other.

So there is everything in harmony and peace on earth?

Down to the level that for example both groups have to share limited resources (aka, the budget)?

You BET, that managers of those groups always fall short and have lots of ideas and would make this world a better place if they only could get a bigger piece of the pie.

Oh, and where could we be if that Java thing would never have happened?

Remember this: In 1996 an analyst report was issued where SAP's technology was called stone age old. After this the stock price dropped.

Could this happen today?

NOT.

So far I haven't seen any Java people shouting commands and swinging a whip, or ABAP people in chains oaring the boat. In fact, I'm sitting with an ABAPer in the same room who is a good friend of mine.

Regards,

Benny

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

> Well. I wonder how that is going on. I'm working for product management in Walldorf, (building 3 for those who know the map). I'm located on level 2. Most of the NetWeaver ABAP development is on level 1 in that same building, while NetWeaver Java sits on level 3 (besides those parts that work in other countries). Due to the nature of their work, both groups care most for their respective servers and don't waste their time by trying to dominate each other.

> So there is everything in harmony and peace on earth?

I think the question is meant to be more "political" or "strategical". I'm sure that ABAP + Java people can sit at the same room without beating each other

> Down to the level that for example both groups have to share limited resources (aka, the budget)?

> You BET, that managers of those groups always fall short and have lots of ideas and would make this world a better place if they only could get a bigger piece of the pie.

I think that the discussions are really taking place when some new component is developed - if it's been developed on Java or on ABAP. Depending on the number of people attending from both groups, I can imagine, that discussions can become really hot about certain topics.

> Oh, and where could we be if that Java thing would never have happened?

> Remember this: In 1996 an analyst report was issued where SAP's technology was called stone age old. After this the stock price dropped.

> Could this happen today?

> NOT.

I'm no SAP employee but I've heard a story (an old wives' tale?) about the "Java intentions" - speaking of a certain advertising from SAPs biggest competitor... and as I said before - IBM and their mainframes (and COBOL, PL/1, IMS etc.) was spoken dead many times - and they are still alive too

<...>

Markus

I think that the discussions are really taking place when some new component is developed - if it's been developed on Java or on ABAP. Depending on the number of people attending from both groups, I can imagine, that discussions can become really hot about certain topics.

As stated a while ago in SAP insider by Franz Fritz (one of our main PDEF executives) "Consider ABAP as for service provisioning and Java for service consumption" (citation from my mind).

That is where we turn currently. Of course there is no dogmatic rule there, but in general new components turn to only a single stack.

I'm no SAP employee but I've heard a story (an old wives' tale?) about the "Java intentions" - speaking of a certain advertising from SAPs biggest competitor... and as I said before - IBM and their mainframes (and COBOL, PL/1, IMS etc.) was spoken dead many times - and they are still alive too

I'm was astonished for a long time, when even ABAP people asked me on trade shows etc. if we would replace ABAP and expected something like we would rewrite all that stuff in two years or so - until I attended the SAP100 course (the basics about ERP): Everything seemed nice and cute and some small order put into the system popped up in material management and book holding - with no hint what happened in the back for this.

Cool, I could write something like that on my desktop with Ruby on Rails in a month! .........NOT!

Regards,

Benny

> As stated a while ago in SAP insider by Franz Fritz (one of our main PDEF executives) "Consider ABAP as for service provisioning and Java for service consumption" (citation from my mind).

> That is where we turn currently. Of course there is no dogmatic rule there, but in general new components turn to only a single stack.

...or they switch later on (speaking of ESS/MSS, CRM Mapbox...)

That approach sounds pretty reasonable.

We upgraded to ERP 6.0 in november and people still use MIGO, VA01 and MM01 to do their business, all that (admittedly) nice-and-nifty looking portal stuff is really a nice to have - but I don't see in the foreseeable future, that people working with the portal only. The whole SOA/ESA stuff will take much more time as expected as cited by the already mentioned analysts and why should we replace a piece of software with a completely new fronted if it's working as it does actually? I don't see the necessity (as of now).

> I'm was astonished for a long time, when even ABAP people asked me on trade shows etc. if we would replace ABAP and expected something like we would rewrite all that stuff in two years or so - until I attended the SAP100 course (the basics about ERP): Everything seemed nice and cute and some small order put into the system popped up in material management and book holding - with no hint what happened in the back for this.

> Cool, I could write something like that on my desktop with Ruby on Rails in a month! .........NOT!

Yes. I know those kind of presentations - very impressing - and working like this almost only in lab-/education environments Exactly from such a presentation (not SAP100) the initial pressure was done on the IT to implement "the SAP Portal". The SAP marketing works really well in that area, honestly. You always have the impression of it being a "must have" when you leave the room.

But if I would seriously remove the SAPGUI from our sales departments PCs and tell them "work with the browser" people would kill me. The same goes for our Material Master guys, if I would take their ALE away and tell them "use XI/PI" for that purpose. Too much code is written by customers to abandon ABAP - and I don't believe that this will happen anytime soon - not in the next decade and even not in the one after that.

Markus

Markus,

I had the pleasure recently to fresh up a program I wrote twenty years ago on a Mac. Doing that work I had to admit how much the world changed in the last twenty years. At that time I used to print out everything (even the stuff that afterwards went into a fax machine), where I today either go directly into the medium (fax) or use completely new ones (mail).

I'm pretty sure, ten years ago, when email was pretty new to most business people I wouldn't have been as productive as this was the old way.

I think we are in that situation with browser front ends now. Yes, they are slower then the GUI. But this advantage gets eaten up from two sides: Web DynPro gets better all the time (hope you noticed that tables got the slide bar back in the latest release, aaaaahhhhhh.... how I missed that) and development does not stop there: the business client, more a specialized browser, will definitely give you the right speed sooner or later.

In general we've been hit over the last years by the fact that both processor power and memory didn't grow any longer like they used to. One because of plain physics and the other because of the 4GB border.

Regards,

Benny

I wouldn´t have a problem with that if it would work.

There are two major drawbacks of that:

- Webdynpro in the browser is ergonomically a nightmare because you can´t use the keyboard any more to navigate (Tab key, cursor keys). You need to enter something, take the mouse, point, get back to the keyboard, enter something, point etc. - This makes the whole ergonomic (and finally the speed and productivity) end up in oblivion. If you talk to people who type a lot in their daily business and using keyboard shortcuts extensively they tell you "nice, thanx - but no thanx". For the management this is certainly a nice thing - but not for the people who work with lots of data - not yet. This may or may not improve in the future.

- WD (both ABAP + Java) doesn´t work very well on non-Windows non-IE platforms. If you have a company policy that forbids the usage of Internet Explorer and urges you to use other browsers, then, well - you´re lost at the second point (try to mass edit users through Firefox on a Portal - and you will understand...)

If we implementing new applications/functions, we always look at what´s there. But talking to the users (speaking of talking to the process people) their opinion is very different. I got just yesterday a call from an SRM user asking me, if there´s the possibility to use the SAPGUI instead of the browser to use the SRM catalog - because it´s so "slow"...

And finally there comes the whole Java administration - which I described in the other post already. As long as this is an piece of somehow together-cluttered "things" then, well, I will do my best to convince our internals to NOT use it/implement it for business critical processes. In my eyes (and the last 3 - 4 years of experience with it) that would be plain negligent. We will of course continue to evaluate and keep testing.

If you start from scratch implementing ERP and/or other applications, you may have a choice but we´re a customer using R/3 since 2.1 (and former R/2) and it´s a really hard way to convince users (including me) to give up speed and ergonomic just for a nice(r) looking browser based frontend.

I´m sure there will be a point in the future where SAP will rewrite certain applications to be available on Webdynpro only but until then, we´re all happy to have maintenance for ERP 2005 using a SAPGUI till 2012.

Markus

Hi Markus,

I wouldn´t have a problem with that if it would work.
There are two major drawbacks of that:
- Webdynpro in the browser is ergonomically a nightmare because you can´t use the keyboard any more to navigate (Tab key, cursor keys). You need to enter something, take the mouse, point, get back to the keyboard, enter something, point etc. - This makes the whole ergonomic (and finally the speed and productivity) end up in oblivion. If you talk to people who type a lot in their daily business and using keyboard shortcuts extensively they tell you "nice, thanx - but no thanx". For the management this is certainly a nice thing - but not for the people who work with lots of data - not yet. This may or may not improve in the future.
- WD (both ABAP + Java) doesn´t work very well on non-Windows non-IE platforms. If you have a company policy that forbids the usage of Internet Explorer and urges you to use other browsers, then, well - you´re lost at the second point (try to mass edit users through Firefox on a Portal - and you will understand...)

I'm using Firefox on my own and complain regularly to everybody I can reach on this...

However, both of your points just need to be fixed, correct?

I´m sure there will be a point in the future where SAP will rewrite certain applications to be available on Webdynpro only but until then, we´re all happy to have maintenance for ERP 2005 using a SAPGUI till 2012.

Well, nobody will force you. If the old stuff fits you, this is OK. As a company, we just have to avoid the situation that somebody else's stuff fit's you and looks better

Regards,

Benny

There are two major drawbacks of that:
- Webdynpro in the browser is ergonomically a nightmare because you can´t use the keyboard any more to navigate (Tab key, cursor keys). You need to enter something, take the mouse, point, get back to the keyboard, enter something, point etc. - This makes the whole ergonomic (and finally the speed and productivity) end up in oblivion. If you talk to people who type a lot in their daily business and using keyboard shortcuts extensively they tell you "nice, thanx - but no thanx". For the management this is certainly a nice thing - but not for the people who work with lots of data - not yet. This may or may not improve in the future.
- WD (both ABAP + Java) doesn´t work very well on non-Windows non-IE platforms. If you have a company policy that forbids the usage of Internet Explorer and urges you to use other browsers, then, well - you´re lost at the second point (try to mass edit users through Firefox on a Portal - and you will understand...)

I'm using Firefox on my own and complain regularly to everybody I can reach on this...
However, both of your points just need to be fixed, correct?

It just can´t be fixed. The widgets in the browser don´t allow e. g. the "cursor down" key to function like they do in SAPGUI, same goes for screen-up and -down, it will scroll the browser content itself, not the grid you are focusing. I may work if you use proprietary Active-X/COM/whatever in the IE but it won´t work in Firefox. Browsers are not (yet) designed for that - they are developed for using a mouse to point and I don´t see any development that will change that in the future.

I´m sure there will be a point in the future where SAP will rewrite certain applications to be available on Webdynpro only but until then, we´re all happy to have maintenance for ERP 2005 using a SAPGUI till 2012.

Well, nobody will force you. If the old stuff fits you, this is OK. As a company, we just have to avoid the situation that somebody else's stuff fit's you and looks better

This is not true - we (as customers) have no choice. If we want to use BI 7.0 we have to use a portal (+ Adobe SVG + Flash + xxx), or we have to use .NET runtime for Analyzer. There is no real choice.

As far as I know all newly developed applications are written using WebDynpro framework (be it ABAP or Java). You can see that e. g. in Solution Manager or in the RampUp versions of SRM - where certain applications are available on WD only - or are being rewritten. Try to use the "self diagnosis" of SolMan with cursor key navigation... (although this is admittedly not a good example).

I understand you as a software company that develops to compete on the market and that still stand means going backwards - but we as customers care about productivity and effectiveness primarily - not on "look".

Markus

To your comments on the usability of Web Dynpro within the browser:

You are correct that there are certainly limitations of running applications within the browser. This is why it is a good thing that SAP didn't lock Web Dynpro into just HTML/JavaScript based rendering. We have alternative rendering path that we call xBCML (Business Client XML). This is what we use in the upcomming Flex Client for Web Dynpro as well as the SmartClient Rendering canvas of the NetWeaver Business Client. These are advances that we stared talking about in ernest at last year's TechEd and should reach customers later this year.

With this approach you can take the exact same Web Dynpro application and run it in a richer environment that supports tabing, shortcut keys, etc - basically addressing the exact concerns that you listed.

Hi Thomas,

I have no doubt that there will be a development focusing on this area and I appreciate it!

What I am saying is, that all that "hype" the presales people do at customers site (or on CeBIT) promoting innovations as of NOW are not really for customers daily work, they look nice in labour environments and you start to implement completely new functions we (of course) always have a look on new technology, new possibilities - just following the development.

Example: We use to have an application in the stock using "sapconsole" (using a telnet client to have a cursor based SAP frontend), we tried to port that application to J2EE using WD and a browser - but it proved to be MUCH slower (in sense of "felt reaction speed" and latency) AND we had pretty much trouble finding a browser (on SymbianOS and Windows CE) that was able to render all things correctly. Eventually our pilot group asked us to get back to the original (telnet based terminal) client which uses a small tiny self written ABAP dynpro (not webdynpro) application. We do even implement that in new areas (factory stocks on other locations) because the J2EE solution wasn't the golden egg.

For the people in the factory it is of course MUCH easier to use an application as NWBC (with a guided procedure) to enter their data than using a full blown SAPGUI with all the options, configurations and fields. I have no doubt, that we will sooner or later implement something like that for certain areas but for the so called "power users" having 8+ SAPGUI modes open (at least 50 % of the users), I don't see any alternative to keep productivity (and speed!) up than continuing to use a SAPGUI.

Markus

It just can´t be fixed. The widgets in the browser don´t allow e. g. the "cursor down" key to function like they do in SAPGUI, same goes for screen-up and -down, it will scroll the browser content itself, not the grid you are focusing. I may work if you use proprietary Active-X/COM/whatever in the IE but it won´t work in Firefox. Browsers are not (yet) designed for that - they are developed for using a mouse to point and I don´t see any development that will change that in the future.

As Thomas already described, it can be fixed in the business client (nothing but a different browser). Of course that means you have to install something additional again. But with the advantage, that everything that runs there runs also in a standard browser.

Well, nobody will force you. If the old stuff fits you, this is OK. As a company, we just have to avoid the situation that somebody else's stuff fit's you and looks better

This is not true - we (as customers) have no choice. If we want to use BI 7.0 we have to use a portal (+ Adobe SVG + Flash + xxx), or we have to use .NET runtime for Analyzer. There is no real choice.

Besides the point, that currently there is entering a whole new company the SAP world (business objects) I'm not really clear what kind of choice you would prefer?

As far as I know all newly developed applications are written using WebDynpro framework (be it ABAP or Java). You can see that e. g. in Solution Manager or in the RampUp versions of SRM - where certain applications are available on WD only - or are being rewritten. Try to use the "self diagnosis" of SolMan with cursor key navigation... (although this is admittedly not a good example).

Guess why your example is not a good one. Surely applications change first in places where new technology is appropriate. I'm not working for solutions, but be sure they won't take away fast data input from you until they have a solution for this. - business client for example.

I understand you as a software company that develops to compete on the market and that still stand means going backwards - but we as customers care about productivity and effectiveness primarily - not on "look".

As you might know, ABAP still contains some technology that is even older then the environment itself. Batch runs, for example are an remainder from punch card times. Why it's still there? Because for some work it's most effective.

I trust in our solution departments to not let you down on effectiveness and productivity. Old things only really go away once they really can be replaced.

Regards,

Benny

I don't see any alternative to keep productivity (and speed!) up than continuing to use a SAPGUI.

OK, Markus,

it's your best right to believe only in what you see. Hope we can demonstrate you the business client to do exactly this around the end of the year.

Regards,

Benny

I don't see any alternative to keep productivity (and speed!) up than continuing to use a SAPGUI.

OK, Markus,
it's your best right to believe only in what you see. Hope we can demonstrate you the business client to do exactly this around the end of the year.

I´ll be happy to evaluate - and show our users because THEY are those, who need to work with it daily for hours - not me.

Markus

As Thomas already described, it can be fixed in the business client (nothing but a different browser). Of course that means you have to install something additional again. But with the advantage, that everything that runs there runs also in a standard browser.

That sounds good. I just have my doubts in using standard HTTP/XML + ERP ES + Business client will "overload" the systems. I have seen our ERP system starts really seriously suffering when e. g. the transfer between CRM and the ERP is switched from proprietary DIAG/RFC to XML - same data - different technology and the backend starts to crawl because of the HUGE overhead of XML although the system is sized for some thousand users. I don´t know yet how the dialogs are done but if each "click" (or navigation) in the BC will do HTTP POST/GET, then... well, it´s to be proved how the system will keep up with that

This is not true - we (as customers) have no choice. If we want to use BI 7.0 we have to use a portal (+ Adobe SVG + Flash + xxx), or we have to use .NET runtime for Analyzer. There is no real choice.

Besides the point, that currently there is entering a whole new company the SAP world (business objects) I'm not really clear what kind of choice you would prefer?

Using non-Windows non-IE based frontends, which is, admittedly, a different topic but it would be nice to be able to do you daily work also with a Linux based frontend or with a Mac.

Guess why your example is not a good one. Surely applications change first in places where new technology is appropriate. I'm not working for solutions, but be sure they won't take away fast data input from you until they have a solution for this. - business client for example.

Ok - another example: Try do add yourself a role in the J2EE without using a mouse., At this place there´s a "standard table grid" used., Can you navigate between the different tabs?

As you might know, ABAP still contains some technology that is even older then the environment itself. Batch runs, for example are an remainder from punch card times. Why it's still there? Because for some work it's most effective.
I trust in our solution departments to not let you down on effectiveness and productivity. Old things only really go away once they really can be replaced.

Well.. I´ve seen pigs fly. And ESPECIALLY in the solutions departments the major opinion is "innovation before stability". I could tell you stories about versions of CRM to today (2.0B to 2005) where really nobody cared about effectivity, migration options and different data models making us sitting there with nothing more than three question marks above our head. Don´t get me wrong, I´m not against innovation or new technology - I just think, that those new things are rolled out to the customers MUCH to early. The CRM 2005 has a nice looking "portal frontend" but intuitive? No, it´s not - it feels like a sedated patient who had a diazepam overdose.

Another horrible example is ESS/MSS (Salary statement). On systems lower than ERP this was an "ITS transaction" using an ITS and the R/3 backend, clean and tidy. Once migrated to ERP you have three J2EE engines, a portal, an adobe document service, various JCo connections, users and passwords and permissions/roles to call those "webservices" - all in all you have 6 machines involved when you do that click to do the same thing you did before. It might look nicer and it might work somehow but troubleshooting that is a nightmare. I was on the opinion that a new technology, once implemented, should make things easier - for the users and the rest, in this case it´s the other way around and I´m not sure if that is good development.

It´s always a fight between technology and infrastructure, developers used to develop on the newest technology - which is good - as long as it works - on the customer side, NOT in IDES labor environments, we all know things are working there

Markus

Another horrible example is ESS/MSS (Salary statement). On systems lower than ERP this was an "ITS transaction" using an ITS and the R/3 backend, clean and tidy. Once migrated to ERP you have three J2EE engines, a portal, an adobe document service, various JCo connections, users and passwords and permissions/roles to call those "webservices" - all in all you have 6 machines involved when you do that click to do the same thing you did before. It might look nicer and it might work somehow but troubleshooting that is a nightmare.>

I share your grief on this count..

~Suresh

> > Another horrible example is ESS/MSS (Salary statement). On systems lower than ERP this was an "ITS transaction" using an ITS and the R/3 backend, clean and tidy. Once migrated to ERP you have three J2EE engines, a portal, an adobe document service, various JCo connections, users and passwords and permissions/roles to call those "webservices" - all in all you have 6 machines involved when you do that click to do the same thing you did before. It might look nicer and it might work somehow but troubleshooting that is a nightmare.>

> I share your grief on this count..

Interesting (and nice) to see that I'm not the only one

What I see in that area is, that there IS development (speaking of SolMan Diagnostics) to help in getting things straight together - which is good and HIGHLY appreciated.

But is it really necessary to have another complete SYSTEM on the same (or even higher) level of complexity set up to maintain something you've done before on "older" technology on a MUCH easier way - and this all "just" to be on the bandwagon and following the SOA/ESA/<insert-new-buzzword-here> marketing people - just *BEFORE* the necessary infrastructure is there to do the necessary monitoring/maintaining?

I mean, SAP has recognized, that there is need for action but shouldn't that have (conceptually at least) been done before the Portal/Business Packages have been rolled out in mass to the customers? No offense against anyone - just what comes to my mind...

I'd be happy to soon upgrade a sandbox system to ERP Enhancement pack 2 and see if the ESS on Webdynpro ABAP will be easier to handle

Markus

I'd be happy to soon upgrade a sandbox system to ERP Enhancement pack 2 and see if the ESS on Webdynpro ABAP will be easier to handle

We are going through that this week and the next....I will let you know.

I'd be happy to soon upgrade a sandbox system to ERP Enhancement pack 2 and see if the ESS on Webdynpro ABAP will be easier to handle

> We are going through that this week and the next....I will let you know.

Great - thanx! We will do the same hopefully on the weekend too

Markus

But is it really necessary to have another complete SYSTEM on the same (or even higher) level of complexity set up to maintain something you've done before on "older" technology on a MUCH easier way - and this all "just" to be on the bandwagon and following the SOA/ESA/<insert-new-buzzword-here> marketing people - just *BEFORE* the necessary infrastructure is there to do the necessary monitoring/maintaining?

Markus, that sounds to me like some projects I have heard about, when people first planned everything before doing the first single step. Unfortunately this would mean to base plans on plans. And this in turn means that your plans on the third level start shaking once you find reality makes you change the base plan.

As I just discussed with some colleagues: the salami is eaten slice by slice, or in the US: the elephant is eaten bite by bite.

Regards,

Benny

> Markus, that sounds to me like some projects I have heard about, when people first planned everything before doing the first single step. Unfortunately this would mean to base plans on plans. And this in turn means that your plans on the third level start shaking once you find reality makes you change the base plan.

I don' think that. One can't e. g. build a car, let people drive with it and "risk" something and THEN start improving it because of "lessons learned".

I could understand your sentence also as "oh - let's buy InQ-My and let's develop some applications on top and call that "portal" and send it out to the customers. Maybe they will like it. If there are any problems we can see, how we can resolve them. And yes, we need to do that quickly because the competitor is out there already offerings something..."

That's of course something you can call a "strategy" - and if it IS really like this, that explains a lot to me then.

> As I just discussed with some colleagues: the salami is eaten slice by slice, or in the US: the elephant is eaten bite by bite.

Of course, there are always problems and fixes - but a correction should be an exception of the rule, not the rule itself. I really can't believe that software is delivered although it's known, that there are problems and errors and that they are fixed then by note corrections, attachments to note and support packages. And honestly: Isn't it sick to have a collection note with number of notes you need to apply after you applied a support package before the support package is actually released?

Markus

 
One can't e. g. build a car, let people drive with it and "risk" something and THEN start improving it because of "lessons learned".

Actually Ford have done that (twice), as have Mercedes. Remember the famous moose test. But I agree that they shouldn't!


Of course, there are always problems and fixes - but a correction should be an exception of the rule, not the rule itself. I really can't believe that software is delivered although it's known, that there are problems and errors and that they are fixed then by note corrections, attachments to note and support packages.

Well it depends on how severe those errors are, whether they're fundamental bugs or corner cases that only occur under an obscure combination of factors. No consolation if your company happens to have that obscure combination - I know you don't, because it always happens to us

Do you think it's possible that the way things are going - all the visual tools, drag and drop 'programming' and that give a false impression that things are simpler than they really are? Like it doesn't look much to change this or that, but underneath it makes a lot of difference.

>> Of course, there are always problems and fixes - but a correction should be an exception of the rule, not the rule itself. I really can't believe that software is delivered although it's known, that there are problems and errors and that they are fixed then by note corrections, attachments to note and support packages.

Well it depends on how severe those errors are, whether they're fundamental bugs or corner cases that only occur under an obscure combination of factors. No consolation if your company happens to have that obscure combination - I know you don't, because it always happens to us

I understand what you mean. What drives me crazy is the fact, that there are just too many proven things that are not really happening - or happening too slow.

I´ve been on a presentation more than one year ago. SolManDiag was presented there as THE solution for maintaining complex multi-system-spanning processes/applications. At that time there was just no tool available to do so - it came with SP12/SP13 of SolMan -which was released at the end of the year. And that´s exactly what I´m criticizing - you shouldn´t tell customers things, that are not yet ready.

And speaking of errors:

% grep -i exception *.trc | wc -l

4564

So we have in our production portal "4564" exceptions. Being it with or without direct enduser affection - I´m also a "user" of the system (the administration user) and it does affect me - because it makes finding real problems almost impossible. And the suggested solution from the support is: "please change your log configuration to SEVERE".

Sorry - if that was the "solution" why can´t it be delivered as such? I´m not disposed to switch the log settings up and down just because developers think that the error is not "severe enough to fix".

If you had an ABAP system having > 4000 dumps in a week, nobody would accept that.

Do you think it's possible that the way things are going - all the visual tools, drag and drop 'programming' and that give a false impression that things are simpler than they really are? Like it doesn't look much to change this or that, but underneath it makes a lot of difference.

That´s the success story of Microsoft: They built something that appears to be as easy as setup-continue-continue-finish - and you´re done- you have a success experience with some easy clicks and "most things" are working. For 80 % of the users this is a prove for the easiness and a cause to implement Windows and Windows applications wherever possible. The complexity is "hidden" behind a nice frontend - which isn´t bad per se - but as soon as you have to dive into internals, it´s becoming VERY complicated and VERY unintuitive. I know MANY people just deleting everything and starting from scratch because it seems to be easier than digging down to fix the error.

It´s the same with SAP software - sapinst, the "setup wizards", the guide procedures - everything appears to be very easy on the first view - and may also work for 80 %. The other 20 % however suffer under the in-depth problems, that are not documented because they are not expected to happen.

Markus

Markus - I think it was Microsoft that introduced the term "just good enough" when it started selling Windows 95.

Rob

I prefer the term "post-release beta test". 😃

I bet Microsoft does too.

Rob

> I bet Microsoft does too.

...and the interesting thing is: There are so many people doing those tests - voluntarily without forcing anyone to do anything. Even beta versions of support packages are spread out and people are eager to "download-setup-next-next-finish-reboot" and see what happens after that.

Markus

I understand what you mean. What drives me crazy is the fact, that there are just too many proven things that are not really happening - or happening too slow.
I´ve been on a presentation more than one year ago. SolManDiag was presented there as THE solution for maintaining complex multi-system-spanning processes/applications. At that time there was just no tool available to do so - it came with SP12/SP13 of SolMan -which was released at the end of the year. And that´s exactly what I´m criticizing - you shouldn´t tell customers things, that are not yet ready.

Actually this is what marketing always criticises about us. You see, talking to developers always is hard, as they want to tell you the things that they do currently and this is usually what you will see a year later. We could do different and let only marketing people talk to you in the future. How about that?

You are right. And you can do something about it. On the next presentation ask this question: "what is already available and what is in planning". I know that many times we present things in planning like it was already there - in fact, I've seen developers who lost the overview and thought their features had reached customer site already.

And the suggested solution from the support is: "please change your log configuration to SEVERE".
Sorry - if that was the "solution" why can´t it be delivered as such? I´m not disposed to switch the log settings up and down just because developers think that the error is not "severe enough to fix".

Did you issue that as an OSS message? The guys sometimes need your pressure to do that.

If you had an ABAP system having > 4000 dumps in a week, nobody would accept that.

An ABAP dump is not comparable to a Java exception....

For example one mechanism on the Java part is that many services start in parallel. Even those that base on each other. So what a service that calls another one does is, it throws an exception and that means the operation just is tried again.

This is a cultural difference - one of those that make you run crazy. Ask the Java guys about ABAP, and you will find some things that are normal to you that drive them crazy.

Do you think it's possible that the way things are going - all the visual tools, drag and drop 'programming' and that give a false impression that things are simpler than they really are? Like it doesn't look much to change this or that, but underneath it makes a lot of difference.

If you don't like them, don't use them. Best way to animate developers to do better.

It´s the same with SAP software - sapinst, the "setup wizards", the guide procedures - everything appears to be very easy on the first view - and may also work for 80 %. The other 20 % however suffer under the in-depth problems, that are not documented because they are not expected to happen.

You don't tell me that sapinst hasn't improved, will you?

By the way: The CE guys tried to replace it and had to move back because of platform support. Another issue that is different in our world.

One thing you also have to watch out for: If you can do 80% of the work in 20% of the usual time, then why shouldn't you do this? Of course you have to know when to do the cut.

Regards,

Benny

Markus, that sounds to me like some projects I have heard about, when people first planned everything before doing the first single step. Unfortunately this would mean to base plans on plans. And this in turn means that your plans on the third level start shaking once you find reality makes you change the base plan.

I don' think that. One can't e. g. build a car, let people drive with it and "risk" something and THEN start improving it because of "lessons learned".

But if you construct a building with a new material and new tools you first need to build and then use. For security reason you would build one level, then carefully decide how stable it is, then build the next level.

Cars are 100 years old, building industry is 5000 years old and they have their rules set up already. I was in the second generation of computer science students. Of course we could have stopped at procedural programming and do it the way you propose.

I see some risk there....

I could understand your sentence also as "oh - let's buy InQ-My and let's develop some applications on top and call that "portal" and send it out to the customers. Maybe they will like it. If there are any problems we can see, how we can resolve them. And yes, we need to do that quickly because the competitor is out there already offerings something..."

Could somebody from the portal step in here? I don't feel like getting into this argument

As I just discussed with some colleagues: the salami is eaten slice by slice, or in the US: the elephant is eaten bite by bite.

Of course, there are always problems and fixes - but a correction should be an exception of the rule, not the rule itself. I really can't believe that software is delivered although it's known, that there are problems and errors

Honestly, there would be not a single piece of software delivered in this world if that would be the case.

>and that they are fixed then by note corrections, attachments to note and support packages. And honestly: Isn't it sick to have a collection note with number of notes you need to apply after you applied a support package before the support package is actually released?

Hm. You know, yesterday I stood in front of a computer, that was constructed, built, and delivered by a man who believed in absolute quality and engineering power. By the time it was delivered, it was the most advanced thing on earth. Called the Next Computer. (The one I saw was, by the way, in the museum of CERN institute, as it carried the first web server ever).

I think you know what happened to this gem of ingenuity.

Regards,

Benny

I don' think that. One can't e. g. build a car, let people drive with it and "risk" something and THEN start improving it because of "lessons learned".

But if you construct a building with a new material and new tools you first need to build and then use. For security reason you would build one level, then carefully decide how stable it is, then build the next level.

Yes -but you don´t build the next level before the other is stable, right? Transferring this to SAP means: You "finished" with NW 7.0, the "Installed Based Maintenace" takes care of the customers and the development fixes serious errors. Everything beyond that is "downporting" from 7.10 (or above), as long as technically possible, correct? So that comparison doesn´t match - not in this case.

Cars are 100 years old, building industry is 5000 years old and they have their rules set up already. I was in the second generation of computer science students. Of course we could have stopped at procedural programming and do it the way you propose.
I see some risk there....

We STILL use a lot of procedural ABAP, even the biggest banks in the world uses COBOL to run their daily business and if I have the choice to use something predictable and deterministic instead of something that does not have those two properties - what will I choose?

And: You still develop on, to and for an already EOL´ed generation of a JDK, which is as ancient compared to Java 6 as is the "100 years of building a car" spoken in speed the computer industry develops.

I could understand your sentence also as "oh - let's buy InQ-My and let's develop some applications on top and call that "portal" and send it out to the customers. Maybe they will like it. If there are any problems we can see, how we can resolve them. And yes, we need to do that quickly because the competitor is out there already offerings something..."

Could somebody from the portal step in here? I don't feel like getting into this argument

It´s exaggerated - and cynical -I know - but I could also cite someone from the "upper management" (whatever that is) who said that a certain advertising was the reason for initially jump on the Java bandwagon - this may or may not be a legend only, I don´t know - to me it sounded pretty reasonable.

Look at the forum here - which is based on a portal too, isn´t it? There are "outages" here too in the forum, for whatever reason, since I´m pretty active and browsing, reading and learning stuff I remark that often. It´s just impossible to have such non-working times if you do business critical things. For the forum here this may not be tragic but if you need to rely on it, it´s a no-go.

Developers are so far away from the daily business of customers - both of the administrators and the users - they just don´t see, that it´s not possible to deploy a "Hotfix for webdynpro" on an almost weekly basis and they do indeed wonder, when you get kind of upset, why you do so. It would be a Good Thing(TM) to send them out to the customers for a week and let them just sit next to the people who work with their development to get a consciousness of the impact and an idea, what it means to run that software. You can write a lot (as I do) but if you never really experience and feel it, you won´t know what I´m talking and writing about.

As I just discussed with some colleagues: the salami is eaten slice by slice, or in the US: the elephant is eaten bite by bite.

Of course, there are always problems and fixes - but a correction should be an exception of the rule, not the rule itself. I really can't believe that software is delivered although it's known, that there are problems and errors

Honestly, there would be not a single piece of software delivered in this world if that would be the case.

So you are saying it´s pretty ok to deliver software, that may impact business seriously by knowing that it will do so? I should cite you next week on our strategy meeting...

What I mean is - we pay hard money for the software - and we expect it to work. If it does not, it´s not our job to find out why it doesn´t and to "prepare" everything - it´s the job of YOU, the job of the SUPPORT to find and fix the error. That´s why we pay maintenance for, right? It´s not a "wishful thinking" or "pleasing" but a DEMAND.

>and that they are fixed then by note corrections, attachments to note and support packages. And honestly: Isn't it sick to have a collection note with number of notes you need to apply after you applied a support package before the support package is actually released?

Hm. You know, yesterday I stood in front of a computer, that was constructed, built, and delivered by a man who believed in absolute quality and engineering power. By the time it was delivered, it was the most advanced thing on earth. Called the Next Computer. (The one I saw was, by the way, in the museum of CERN institute, as it carried the first web server ever).

Yes - but I don´t really get the relation to the sentence above - what do you want to tell me?

Markus

I understand what you mean. What drives me crazy is the fact, that there are just too many proven things that are not really happening - or happening too slow.
I´ve been on a presentation more than one year ago. SolManDiag was presented there as THE solution for maintaining complex multi-system-spanning processes/applications. At that time there was just no tool available to do so - it came with SP12/SP13 of SolMan -which was released at the end of the year. And that´s exactly what I´m criticizing - you shouldn´t tell customers things, that are not yet ready.

Actually this is what marketing always criticises about us. You see, talking to developers always is hard, as they want to tell you the things that they do currently and this is usually what you will see a year later. We could do different and let only marketing people talk to you in the future. How about that?

I´m sorry - you are telling me you don´t know what the software is able to do on a level, that is delivered to the customers? Hugh? Did I miss something?

You are right. And you can do something about it. On the next presentation ask this question: "what is already available and what is in planning". I know that many times we present things in planning like it was already there - in fact, I've seen developers who lost the overview and thought their features had reached customer site already.

I did that - and guess what.. you NEVER get a clear answer. Either the people are from "presales" and don´t know enough because they present high-gloss marketing material on a very high level or they are developers who start talking nuts where maybe 5 % of the audience can follow (me excluded). There are just no people "in between" - at least that´s the impression I have. Especially on the SolMan area this is devastating, you talk to three people and you get three different answers about which service pack includes what. I´m sorry - but this doesn´t improve any trust in the software if the company who´s developing it, can´t tell what is available and what is planned/future

And the suggested solution from the support is: "please change your log configuration to SEVERE".
Sorry - if that was the "solution" why can´t it be delivered as such? I´m not disposed to switch the log settings up and down just because developers think that the error is not "severe enough to fix".

Did you issue that as an OSS message? The guys sometimes need your pressure to do that.

Yes - I did, I got told there´s a "Log cleaning task force" (or something like that) - but I finally got sick of it and closed the call - because - as said in the other thread - I´m a paying customer and I´m not disposed to beg or please something, if they don´t want because there are things with higher priority on their list, well - I have no chance - or I get another "customer hotfix for service pack XY" - what I can nicely abstain from.

If you had an ABAP system having > 4000 dumps in a week, nobody would accept that.

An ABAP dump is not comparable to a Java exception....
For example one mechanism on the Java part is that many services start in parallel. Even those that base on each other. So what a service that calls another one does is, it throws an exception and that means the operation just is tried again.

Why can´t one implement a dependency tree for that? If that is such a basic problem and causing many many errors that confuse people and if the solution is that "easy"? I know why: because nobody knows them.

I have a call open now for > 19 months asking, which of those applications are absolutely necessary to run a portal and which ones can be disabled. The answer is still not there. We initially planned to implement an external facing portal - but due to the impossibility to get that above information and due to security considerations we switched to a different software after having postponed the project for almost a year waiting for a statement (CSN 401279/2006).

>> This is a cultural difference - one of those that make you run crazy. Ask the Java guys about ABAP, and you will find some things that are normal to you that drive them crazy.

Sure - but there´s nobody available to explain me the reason cause and fix for those "exceptions" (cite "it´s not the work of the support to educate customers"), there are no education courses for that aside from attending a JAS* (I´m not intending to become a Java developer), on the ABAP side this is very different.

And even IF I would attend a Java development course it won´t help. If I click somewhere in the portal and I get an "ERROR 500" (which is pretty common) all I have is this "click" and maybe an exception "somewhere" - or maybe not. I can´t even distinguish between a systemical, SLD´ical or an application (means Business Package) error, even IF I have an exception. All I can do is "guess" from the names in the stack an average direction, which may or may not be right. The story continues then in the OSS where the message is forwarded to various groups/components, each person is trying to help, figure out, asking for reproduction etc. etc. - it´s so utterly time consuming and you know where you end? Someone telling you to follow the documentation to setup and check SLD, JCo, user, passwords, roles, backend configuration etc. etc. . All I can say then is "thank you for this (crap) - but no thank you".

The whole thing doesn´t follow a concept (I can´t see one), some applications use SLD; some not, some need configurations in the backend, some not - and BC-JAS is as less as we are able to find out a cause of an error. If someone would try to convince me to change my opinion to "technologically outrageous" I would just laugh loud

Do you think it's possible that the way things are going - all the visual tools, drag and drop 'programming' and that give a false impression that things are simpler than they really are? Like it doesn't look much to change this or that, but underneath it makes a lot of difference.

If you don't like them, don't use them. Best way to animate developers to do better.

That´s a good statement, I´ll keep that in my mind

>> > It´s the same with SAP software - sapinst, the "setup wizards", the guide procedures - everything appears to be very easy on the first view - and may also work for 80 %. The other 20 % however suffer under the in-depth problems, that are not documented because they are not expected to happen.

You don't tell me that sapinst hasn't improved, will you?

I´ve installed roughly 90 - 100 systems in the last two years, many of them were test/evaluation/sandbox/copies systems on various operating system/database combinations, most of them are gone now, only a few are production systems. sapinst has definitely improved - no doubt (I will omit the "but"-sentence)

By the way: The CE guys tried to replace it and had to move back because of platform support. Another issue that is different in our world.
One thing you also have to watch out for: If you can do 80% of the work in 20% of the usual time, then why shouldn't you do this? Of course you have to know when to do the cut.

It works 80 % ONLY if you start a new installation. Everything beyond that is out of scope.

To stay with the SolMan example: We upgraded our Solman from 2.1 to 2.2, then new installation and migration to 3.1, upgrade to 3.2 and now upgraded to 4.0. ALL the BC-Sets and the preconfigured stuff available for new installation will not work on our system, it can´t be applied because it would overwrite our customizing (we have about 8.500 support desk calls in it). Those sets are neither available for upgraded systems nor are they somewhere documented --> We´re lost.

After the upgrade we needed two weeks to get the system back to a state, where people could work with it.All the CTC-Wizards (Template installers) won´t work on upgraded systems (and yes, we upgraded 6.40 to 7.00 WebAS Java) so we need to do EVERYTHING by hand - without any complete documentation, without any information about relations between the ABAP + Java part - plain nothing. The support told us: "Get a consultant to configure that". We said: No.

That just proves, that one should by not means listen to marketing people, we started to early and now we´re alone - just because one always forgets the customers and installation, who are there.

(sorry - again so long...)

Markus

Hi,

>This is a cultural difference - one of those that make you run crazy. Ask the Java guys >about ABAP, and you will find some things that are normal to you that drive them crazy.

Agreed. That's one of the reason why it was a very bad idea to create dual stack products : Half of the crowd will always run crazy...

Regards,

Olivier

> Agreed. That's one of the reason why it was a very bad idea to create dual stack products : Half of the crowd will always run crazy...

> Regards,

> Olivier

At the time it was a nice idea for several reasons. As always it is a little bit too easy to judge history backwards...That the idea turned to something else you can see from the fact that we now tend to swap things into a single stack.

Regards,

Benny

> Agreed. That's one of the reason why it was a very bad idea to create dual stack products : Half of the crowd will always run crazy...

> Regards,

> Olivier

I think it should be "The whole crowd will always run crazy...",

because both halves will be running crazy about the other stack..:)

Regards,

Ravi Kanth Talagana

Actually this is what marketing always criticises about us. You see, talking to developers always is hard, as they want to tell you the things that they do currently and this is usually what you will see a year later. We could do different and let only marketing people talk to you in the future. How about that?

I´m sorry - you are telling me you don´t know what the software is able to do on a level, that is delivered to the customers? Hugh? Did I miss something?

No. As you might know we deliver ships rather then cars. Means what is put together today usually is delivered at least months later to customers. That has many reasons, like production, quality assurance and others. Additionally not all customers do upgrade on the first possibility. On top of that, your calculation when delivery will reach customers may go completely blast.

It helps a lot if you just categorize things you hear strictly into "is available" and "will be available". The latter always means "planned" and therefore is insecure even is a planned date is given.

The only exception is features that have been approved to customers for specific projects and only in written form. To my experience this never happens with technology.

I did that - and guess what.. you NEVER get a clear answer. Either the people are from "presales" and don´t know enough because they present high-gloss marketing material on a very high level or they are developers who start talking nuts where maybe 5 % of the audience can follow (me excluded). There are just no people "in between" - at least that´s the impression I have. Especially on the SolMan area this is devastating, you talk to three people and you get three different answers about which service pack includes what. I´m sorry - but this doesn´t improve any trust in the software if the company who´s developing it, can´t tell what is available and what is planned/future

TELL THEM!

Next time you have a concrete question I can tell you where to get the right answer as there is a single point of information that has to know and that is product management.

Did you issue that as an OSS message? The guys sometimes need your pressure to do that.

Yes - I did, I got told there´s a "Log cleaning task force" (or something like that) -

That is my information too. And guess what: this won't happen overnight.

(CSN 401279/2006).

Markus,

I read through this and I'm aware of all the actions taken. You personally stirred up development a little bit I'm not going to open up all this issues again. As your mentioned discussion in the Internet blogging sphere shows you are in general disappointed how Java works at all. Sorry for that, we're working on it and again it cannot be done over night.

Don't think I want to stop an unpleasant discussion, your name and your postings go to my personal collection of complaints that I work with.

Regards,

Benny

No. As you might know we deliver ships rather then cars. Means what is put together today usually is delivered at least months later to customers. That has many reasons, like production, quality assurance and others. Additionally not all customers do upgrade on the first possibility. On top of that, your calculation when delivery will reach customers may go completely blast.

In that case I would expect a "First Customer Shipment" or any CLEAR statement, that the software is to be considered "preliminary" (or whatever) and not let the customers get the impression, that everything is finished already

It helps a lot if you just categorize things you hear strictly into "is available" and "will be available". The latter always means "planned" and therefore is insecure even is a planned date is given.

The big problem with those high-gloss powerpoint is, that you can never distinguish between "software function", "strategy" and "vision". On many occasions my collegues ask me "what is now what" or "how did you understand that" after a presentation. Just look at the Netweaver overview slide, a technical person won´t find anything and the strategic person won´t find either because it´s a mixture of it all.

TELL THEM!
Next time you have a concrete question I can tell you where to get the right answer as there is a single point of information that has to know and that is product management.

Ok... I will try (again)

(CSN 401279/2006).

Markus,
I read through this and I'm aware of all the actions taken. You personally stirred up development a little bit I'm not going to open up all this issues again.

The problem is, all that reaches me is policy of appeasement. I didn´t get any direct feedback nor did I know that I "stirred up development"; it was not my intention to tap on someones feet. I just call things by name and I may be too demanding or sometimes be read as harsh but in any case I prefer a solution rather than a workaround, means, I don´t want to stick my head into the sand and "keep as is". I´m sure there are people hating me for that but I can deal with it

As your mentioned discussion in the Internet blogging sphere shows you are in general disappointed how Java works at all. Sorry for that, we're working on it and again it cannot be done over night.

I'm aware of that - totally. I could deal with the current situation if there was a methodology to find out, where a problem is (and in fact IF there is a problem). Something like that doesn't exist, all I can do is take the setup/configuration guide and check all the things by hand. The whole troubleshooting on customers side is based on "guesses" which doesn't help me in trusting that software.I'm not able to do anything but "guess" the correct component, "guess" the correct logfiles and open an OSS call.

Don't think I want to stop an unpleasant discussion, your name and your postings go to my personal collection of complaints that I work with.

I know... I didn't want to roll up that message again here - I appreciate that you took the time and read the message and commented on it - even if I'm now graylisted

Markus

No. As you might know we deliver ships rather then cars. Means what is put together today usually is delivered at least months later to customers. That has many reasons, like production, quality assurance and others. Additionally not all customers do upgrade on the first possibility. On top of that, your calculation when delivery will reach customers may go completely blast.

In that case I would expect a "First Customer Shipment" or any CLEAR statement, that the software is to be considered "preliminary" (or whatever) and not let the customers get the impression, that everything is finished already

Just for the records: I did not say we deliver any preliminary software to customers. It may be that developers when talking to customers easily get into a mode where they talk about features that they currently work on, which sometimes leaves the impression that this is already available.

The big problem with those high-gloss powerpoint is, that you can never distinguish between "software function", "strategy" and "vision". On many occasions my collegues ask me "what is now what" or "how did you understand that" after a presentation. Just look at the Netweaver overview slide, a technical person won´t find anything and the strategic person won´t find either because it´s a mixture of it all.

In my presentation I'm doing a Q&A after the presentation and usually are available even after that for additional questions. And I know that most of my colleagues do that the same way. Additionally we do have many other services including the forums in here, where those questions can be discussed until it is clear to you. We know it is not an easy task to explain that stuff and are always on the run to improve.

The problem is, all that reaches me is policy of appeasement. I didn´t get any direct feedback nor did I know that I "stirred up development"; it was not my intention to tap on someones feet. I just call things by name and I may be too demanding or sometimes be read as harsh but in any case I prefer a solution rather than a workaround, means, I don´t want to stick my head into the sand and "keep as is". I´m sure there are people hating me for that but I can deal with it

Well, that's not appeasement, thats a result of the general company policy not to talk to the outside about internal processes or actions (even though I sometimes feel I walk the border), which follows as a consequence from legal rules (That is what makes politicians talk the way they talk and sometimes I have to follow this too....)

With 'stirr up' I just meant you initiated some action - that is exactly what should happen after customer complaints. Nobody was hurt or felt insulted.

I know... I didn't want to roll up that message again here - I appreciate that you took the time and read the message and commented on it - even if I'm now graylisted

You're not...

Regards,

Benny

Just for the records: I did not say we deliver any preliminary software to customers. It may be that developers when talking to customers easily get into a mode where they talk about features that they currently work on, which sometimes leaves the impression that this is already available.

Ok - I got this point

In my presentation I'm doing a Q&A after the presentation and usually are available even after that for additional questions. And I know that most of my colleagues do that the same way. Additionally we do have many other services including the forums in here, where those questions can be discussed until it is clear to you. We know it is not an easy task to explain that stuff and are always on the run to improve.

Yes, many people do that indeed and I'm aware it's not easy to explain even if you finally "understood" what is meant.

A good example that always causes confusion is help.sap.com. It's really well consistently structures with the powerpoints customers are shown to. The issue is, that it's still not clear, what is the "software", what is the "configuration" and what is the "process" as less as it is in the powerpoints.

In the "early days" that kind of documentation was structured in e. g. "Basis", "SD" and/or "MM" and cross linked - which is very understandable from a logical point of view for almost everyone.

Today you have things like "Power User’s Guide" or "Enabling Application-to-Application Processes" which is a total mixture of functionality, process and software. Searching there for a specific information is almost impossible. In the total antagonism to that, you have paradigms like CMV to exactly separate the function/process from the data from the software.

I'm VERY aware, that writing documentation for a SAP system is a VERY difficult job and I don't wanna be responsible for doing that. I just hear in internal meetings, that finding an information for a certain functionality is nowadays almost impossible (on help.sap.com). Many of my collegues still use the 4.6c documentation and then try to "reflect" that to the ERP just because they are unable to find the necessary help.

The problem is, all that reaches me is policy of appeasement. I didn´t get any direct feedback nor did I know that I "stirred up development"; it was not my intention to tap on someones feet. I just call things by name and I may be too demanding or sometimes be read as harsh but in any case I prefer a solution rather than a workaround, means, I don´t want to stick my head into the sand and "keep as is". I´m sure there are people hating me for that but I can deal with it

Well, that's not appeasement, thats a result of the general company policy not to talk to the outside about internal processes or actions (even though I sometimes feel I walk the border), which follows as a consequence from legal rules (That is what makes politicians talk the way they talk and sometimes I have to follow this too....)

Yes - I understand that from a legal point of view undoubtedly. I just don't know, how you would react, if you are waiting for a LONG time for an answer and all you get is "please wait, we're working on it..." and there are dates and deadlines in the background, maybe even backed up with some money that you get or not get - just because you're not able to get ANY information about progress.

With 'stirr up' I just meant you initiated some action - that is exactly what should happen after customer complaints. Nobody was hurt or felt insulted.

Ok - I'm fine now (again)

>> even if I'm now graylisted

You're not...

even better! It's nice discussing here

Markus

> At the time it was a nice idea for several reasons. As always it is a little bit too easy to judge history backwards...That the idea turned to something else you can see from the fact that we now tend to swap things into a single stack.

... and that's a Good Thing(TM).

Markus

Eventually, ABAP will die out. But it won't matter because something better (probably not even imagined about now) will replace it. We will learn that and move on.

Change and learning is good.

Rob

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

> Eventually, ABAP will die out. But it won't matter because something better (probably not even imagined about now) will replace it. We will learn that and move on.

Well.. I don't think so.

Just see the actual development on the mainframe - mainframes were told to be dead a decade (or more) ago - and they are coming back, with modernized environments. E. g. the whole virtualization discussion going on was done on mainframes long ago before even someone though about this becoming valuable on a "commodity hardware".

Additionally I have seen quite a few big companies (Bank/Insurance sector) urgently seeking for COBOL developers because those who know that language are mostly retired and that it isn't taught any more in school and it's not possible for them, to "port" their old mature and working applications onto a total new platform.

What I find very interesting is the development in some SAP areas: ESS/MSS in ERP 6.0 is a full Java webdynpro application. In Enhancement pack 2 there has been quite a lot of development to get it back to ABAP and replace the Java WD with ABAP WD. I also see that direction in other areas too (CRM). Either this is driven solely by customer demand only or people @ SAP have finally noticed, that Java is not the "jack of all trades, master of none". In both cases it's interesting to see, that ABAP is been improved heavily.

I for myself can say (my personal opinion): if at anytime in the future (and I'm sure many people are already working on it) Java will become as mature and as stable as ABAP is - why not. But as of now, it's a complete mess (I heard people saying "utter piece of crap") because of it's mega-complexity and layer on top of layer on top of layer and the total lack of background information about those layers. ABAP may be monolithic and proprietary and for sure has drawbacks also - but I never had THAT MUCH trouble to get an application stable and administrable, not with release 2.2D and not with ERP 6.0.

Markus


But as of now, it's a complete mess (I heard people saying "utter piece of crap") because of it's mega-complexity and layer on top of layer on top of layer and the total lack of background information about those layers. ABAP may be monolithic and proprietary and for sure has drawbacks also - but I never had THAT MUCH trouble to get an application stable and administrable, not with release 2.2D and not with ERP 6.0.

Is that the language itself or all the libraries, frameworks and toolkits that go with it?

P.S. 2.2D? newbie!

Hi Markus,

> >I for myself can say (my personal opinion): if at anytime in the future (and I'm sure many people are >already working on it) Java will become as mature and as stable as ABAP is - why not. But as of now, >it's a complete mess (I heard people saying "utter piece of crap") because of it's mega-complexity and >layer on top of layer on top of layer and the total lack of background information about those layers. >ABAP may be monolithic and proprietary and for sure has drawbacks also - but I never had THAT MUCH >trouble to get an application stable and administrable, not with release 2.2D and not with ERP 6.0. >

If I had better English writing skills, I could have written exactly the same paragraph !

We share exactly the same opinon on Java SAP. The admin nightmare are, for me, dual stack products which increase a lot TCO. The Netweaver application server is a marketing wet dream : there are 2 completely separate app servers (abap and java) tied down with very little software glue...

So, I'm happy to welcome you in my private "old grunt SAP admins" !

Regards,

Olivier

I´m talking about administration - I don´t deal with Java programming (thankfully), I "just" have to administer the system. My concerns are more about conceptional deficiencies. I´m sure there are reasons why the development chose to do things initially the way they are now but

- why maintaining administration users on two different places (UME + "secure store") - wihtout even a notice if one of those is change to not forget to the change the other?

- why storing everything in the database and then copying to the filesystem because of "performance reasons" and so being unable to backup consistently without shutting down everything?

- why still using an ancient already EOL´ed JDK and not "porting" to something newer if wanting to be technology leader?

- why the need of an additional monitoring platform (SolMan Diagnostics) - which is built on top of the same (deficient) stack and not enabling the engines themselves to to the same?

- why installing Java applications on platforms that are known to be not working/not being supported (speaking of Adobe Document Services)?

- why having 10.000s of "exception" logged in the default.X.trc file if they are no real exceptions/errors?

- why do I get the impression that when I open calls in the Java area of being just the typist of the bug tracking system and being just another exception-annoyed customer?

- why can´t Java application names be descriptive (speaking of "what is td_wais_sdbi~replan")?

- why is the configuration of Java applications so utterly inconsistent? Some use SLD read-only, some read/write, some use "fixed systems" in the portal - and more the question: how to monitor that diversity?

<...>

Maybe I´m seeing those things just a bit too much out of the "ABAP glasses", I don´t know.

It´s the sheer mass of tools and parameters and dependencies (JSPM, SDM, configtool, visual admin, offlinecfgeditor, log viewer, nwa, solman diagnostics (and its agents), used JDK version and the java parameters depending on usage type, dependencies between ABAP + Java SP versions etc. etc. etc.) which makes the system and its administration an utter MESS - nothing but that in my eyes.

Many people and consultants told me, it´s "not bad" to have e. g. thousands of logged exceptions/errors in the logfiles - as long as no users complains and you have no "visual appearance" of an error. Well - congratulations - maybe that´s the way of dealing with it - by burying the head in the sand. For being the biggest software factory in Europe and for the fact, that we - the customers - PAY money (means $$$) for the software, I expect a bit more than answers like "please ignore that message" (which is just one example).

Markus

Markus,

Perfect description of the SAP Java administration nigthmare !

But Mr Agassi is no more here to clean the mess he left, he is now driving his electric car....

Olivier

Actually the wrong question here is being asked --perhaps we should look at the basic SAP systems themselves. A lot of the old processes and screens look really old fashioned, hard to use and have almost ZERO customer / user configurability - and those that do must have been designed by someone who can only see purple and pink -- talking about the Colour scheme options on the SAP GUI .

Programming Languages are just that. It's the applications themselves that are important. These must be reliable, robust, secure when required and be easily maintainable.

Java fails definitely in the last scenario as the nr of different components etc that have to be done to actually deploy an application can only make the mind boggle and no wonder it's an admin nightmare.

Web usage is definitely here to stay whether management likes it or not. Users also want to integrate data with office aps like EXCEL etc.

Have you ever tried using a web query via ABAP. Excel does it easily in a matter of seconds.

Languages like php might well come back here as they integrate with the web very easily.

ABAP has more or less run its course -- It will stay around for sure for a while yet but the real problem is in designing easily administrable robust secure systems that can be used in a global market place.

A Language that was born out of a mixture of COBOL and PL/1 by some ex-ibm'ers has done well over the period --but its number is definitely up.

I think if you want to see the current state of play in ABAP and unfortunately the total lack of web / e-commerce / new technology understood by the "supposed next generation of abappers" just read some of the Posts on the ABAP Forums.

Most of those guys I wouldn't even have as Car Park Cleaners - never mind getting them to do programming applications for multi-million / billion dollar corporations.

Some guys are still coding as if they were writing a Batch 1960 -1970's type application and the web could be in a different universe as far as they are concerned.

Anybody even attempted to write a good TEXT SEARCH algorithm in ABAP etc.

These are sorts of Apps that USERS require and still find it hard to get those that even work half way decently.

Cheers

Jimbo

> Programming Languages are just that. It's the applications themselves that are important. These must be reliable, robust, secure when required and be easily maintainable.

> Java fails definitely in the last scenario as the nr of different components etc that have to be done to actually deploy an application can only make the mind boggle and no wonder it's an admin nightmare.

Well - when I see the number of "outages" here in the SDN (and today also in the SMP?) I wouldn't dare to call the "reliable" or "robust" (admittedly without knowing the real reason behind).

<...>

> Languages like php might well come back here as they integrate with the web very easily.

Yes - but the problem of PHP is against the "Controller - Model - View" paradigma - PHP mixes up presentation and logic and exactly the other way Java goes (abstraction over abstraction driven to oblivion.

> ABAP has more or less run its course -- It will stay around for sure for a while yet but the real problem is in designing easily administrable robust secure systems that can be used in a global market place.

I don't think that ABAP will be gone soon.

> A Language that was born out of a mixture of COBOL and PL/1 by some ex-ibm'ers has done well over the period --but its number is definitely up.

As I stated on some pages before already one of the biggest banks in the world run their daily business also (amongst others) with COBOL programs.

<...>

> Some guys are still coding as if they were writing a Batch 1960 -1970's type application and the web could be in a different universe as far as they are concerned.

I'm sure so and if it makes sense for the specific requirement - where's the problem? If an application allows to be batch driven and does its job I don't see any arguments why it shouldn't be done so. Just see how many (big) companies replaced their Windows XP for Vista (or better said, how many of them did NOT do that). XP does its job pretty nicely, has developed to be stable enough for daily work. Just because Vista is now "state of the art" that's not enough arguments to switch over a whole well-known (and well-issue-known) basis of your daily work - for many companies including the one I'm working in.

> Anybody even attempted to write a good TEXT SEARCH algorithm in ABAP etc.

I agree.

> These are sorts of Apps that USERS require and still find it hard to get those that even work half way decently.

Well - there are better methods of doing text searching than trying to (re-)program that in ABAP (e. g. TREX). If "text searching" is a fundamental part of the application you're going to write, I would definitely look for alternatives instead of trying to code that in ABAP.

Markus

Come on...Don't tell that you believe that -;) ABAP will never going to get obsolete (Or at least not in the next century...)

R/3 and NetWeaver were build on ABAP...So how can it get obsolete or change in favor of Java?

Both technologies coexist and that's great, but ABAP is going to be always the best -;)

Greetings,

Blag.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

The brother in law from the friend of the hairdresser of the wife of SAP CEO told me to run away from abap systems...

Ask your Java developers how long it will take them to reprogram in java the 15000+ transactions of SAP ERP software...

When I experiment every day the mess of SAP java administration, I apreciate more and more the abap stack...

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

> When I experiment every day the mess of SAP java administration, I apreciate more and more the abap stack...

To read that from YOU makes my day much more bearable - honestly

Markus

Hi Markus,

>To read that from YOU makes my day much more bearable - honestly

Why especially from me ?

Am I ranting so much ?

We have a saying in French : Who likes someone well, punishes him well...

It's difficult to translate but you get the idea !

Regards,

Olivier

Yes there ARE still batch type applications that still work and are OK for the purpose such as large payroll stuff -- but there are a HUGE number of new applications that need to be run online that never existed in the 70's and 80's such as immediate online stock trading, forex, online betting (whilst not regarded as a "serious business" by many I can assure you this is a very very big business indeed) etc etc..

Other applications which while not so time critical also need reasonably interactive feedback with the user such as ESS, Workflow processes where approvals need to be managed sensibly, JIT ordering / stock management, Online payments, hotel bookings, travel reservations, gig reservations etc etc.

If SAP wishes to integrate a lot of these types of applications into its business then some of the older traditional SAP methodology must be chucked out of the window as these type of apps are not suited to "classical ABAP" type programming or even the traditional SAP architecture. For example FOREX trading systems are often built up using a special purpose language MQL which is more appropriate to that type of activity than ABAP could ever be.

I agree updating for updating's sake is not a good idea -- but the methods of retrieving and using data today are really so far removed from the traditional SAP Central Data Base server(s) model that newer techniques (and hence programming methodology) must also be designed to handle these.

Data often has to be retrieved from all over the web in a totally random fashon - depending on what the user is trying to do.

Not an easy task - especially for Admin when many different types of technology need to be used.

SAP will lose out in the end if it fails to make provision for competing in these markets otherwise it will ultimately die -- just look at the typical power of a lowly workstation these days -- who nows what future generations of users will dream up to use on their machines.

cheers

jimbo

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Yes there ARE still batch type applications that still work and are OK for the purpose such as large payroll stuff -- but there are a HUGE number of new applications that need to be run online that never existed in the 70's and 80's such as immediate online stock trading, forex, online betting (whilst not regarded as a "serious business" by many I can assure you this is a very very big business indeed) etc etc..

Yes - I agree.

Other applications which while not so time critical also need reasonably interactive feedback with the user such as ESS, Workflow processes where approvals need to be managed sensibly, JIT ordering / stock management, Online payments, hotel bookings, travel reservations, gig reservations etc etc.

Well - exactly in the ESS there are developments ongoing started with enhancement pack 2 to get the ESS stuff back into ABAP, namely Webdynpro ABAP.

If SAP wishes to integrate a lot of these types of applications into its business then some of the older traditional SAP methodology must be chucked out of the window as these type of apps are not suited to "classical ABAP" type programming or even the traditional SAP architecture. For example FOREX trading systems are often built up using a special purpose language MQL which is more appropriate to that type of activity than ABAP could ever be.

Yes- but in that case the software itself would be the wrong choice. I´m not sure if the "SAP Banking" Addon is completely developed in Java (or in something else) - I seriously doubt so.

I agree updating for updating's sake is not a good idea -- but the methods of retrieving and using data today are really so far removed from the traditional SAP Central Data Base server(s) model that newer techniques (and hence programming methodology) must also be designed to handle these.

I´m not sure if that is the case. We come from (initially) R/3 2.1c and upgraded to ERP 6.0 last november, and most of the people still use their MD04 and VA01 to do their daily business. Given the fact, that all the industry solutions (but one) were retrofitted BACK into the ERP system instead of being a separate addon makes me thing vice-versa. New applications however, are designed with a a different focus, true, but the legacy is still there and is constantly enhanced.

Data often has to be retrieved from all over the web in a totally random fashon - depending on what the user is trying to do.

You were attending a SOA/ESA/<insert-buzzword-here> presentation? Just kidding... you´re right. However, we still prefer using ftp/sftp to transfer data to and from external locations. We evaluated XI/PI last year but we came to the conclusion that it´s totally oversized. Simplicity is THE key factor, which means, we have now just plain textfiles, that anybody can read, we have ONE system transferring that data, we don´t need to take care of another doublestack installation and we don´t need to educate people to check their data transfers using XI/PI. The "gap" between sending the data and the retrieve and process on the other side is max. 5 minutes - we´re just not so JIT that we need less and if that would be the case, we would just decrease the cycle for the transfers.

There may or may not be requirements in the future, that would make us to change that - but as of now, we´re running that scenario pretty successful without any trouble. Simple protocols (ftp), simple textfiles (that can be parsed also using ABAP) and ONE system, not two or three.

Not an easy task - especially for Admin when many different types of technology need to be used.

I don´t have a problem with different technologies as long as I am made able to monitor and administer those. I have all in all (including Test + QA) 56 SAP systems (instances) to take care of, 21 of them are J2EE engines. As a rough estimate I would say, that I spend 80 % of my time fiddling with the Java stuff. On ABAP systems, I can automate and script almost anything, starting with kernel patches going even to support packages, if required.

On Java I have to maintain the system one-by-one, deploying here, configuring using offlinecfgeditor there etc. etc. There´s no way of automating things here easily Try to apply Java support packages unattended (or just a "Hotfix for webdynpro") - without sitting in front of the screen and "click around" and wait.As of now it´s not really possible.

And to stay with the ESS example: I´m not sure if it´s "cheaper" (speaking of money and time) to print out the salary statements and use a letter to send them to the people instead of building up a multi-system infrastructure zoo with (just for this scenario) 5 boxes so people are enabled to print them on their own - and I´m not speaking of hardware costs here. It may be nice and nifty but in my u understanding the benefit is totally overestimated.

SAP will lose out in the end if it fails to make provision for competing in these markets otherwise it will ultimately die -- just look at the typical power of a lowly workstation these days -- who nows what future generations of users will dream up to use on their machines.

They can (and should) do that - no doubt. They just should not force customers to use that technology and leave the choice at them - keep it simple.

Markus

Speaking of ESS, and going back to the "delivered before it's ready" points, I worked for a company that implemented it 5 years ago, and ripped it out a year later. The main reason being that the third-party software provider that provided the key software between SAP and the email client "didn't wish to support the software", so they had little choice but to rip the buggy thing out 😛

We are just on the way to upgrade a sandbox to enhancement pack 2 to see if the WD-ABAP will work better. I´m sure I won´t get any "Error 500"

Markus

This is quite an interesting thread.

Markus, you have some fairly strong opions, some/most of which I agree with.

Don't you think that you are being a little unrealistic, however?

The general gist of what you are posting seems to be that SAP is not the perfect software company, and in moving to a new platform they are making some mistakes.

Until we remove humans from the process, mistakes will always be made. SAP, however, seem to be doing things better than most - your company bought their products, no?

Before you say thats marketing over substance, being the other way isn't great either. The perfect product with no customers is not a good option for anyone - ie your calls to a support line getting a disconnected message.

Everyone has their war stories (god - did anyone else go rampup with MDM 5.5?), but generally SAP products match the hype, even if sometimes this takes time. You seem quite happy with the ABAP stack as it now stands but when R/3 replaced R/2 that was hardly a seamless transition - do you remember the pain?

Hi Brad,

Markus, you have some fairly strong opions, some/most of which I agree with.
Don't you think that you are being a little unrealistic, however?

The general gist of what you are posting seems to be that SAP is not the perfect software company, and in moving to a new platform they are making some mistakes.

I am aware of that - and I see, that the software is continuously improved.

Until we remove humans from the process, mistakes will always be made. SAP, however, seem to be doing things better than most - your company bought their products, no?

Yes - we did but the reason for that was not marketing. The reason is on one side "historical" (due to our R/2 past) and the lack of real good alternatives.

SAP is a stock corporation and they have to keep the same and the investors happy.

Before you say thats marketing over substance, being the other way isn't great either. The perfect product with no customers is not a good option for anyone - ie your calls to a support line getting a disconnected message.

See for this point

You can´t (or should I say you shouldn´t) put any software on the market if you don´t have the support ready (which means people, tools and knowledge). An OSS call with Java still takes at least the double amount of time than the same on ABAP and still customers are not enabled to "help themselves" because knowledge transfer doesn´t take place. As a customer you get the info "click here and there". If it works, it´s good - if not, then you need to open a call. What is really happening when you "click here", is not known - sometimes even not from the support people.

I generally would never say, that SAP is a bad company - in contrary! The working environment for the employees is superior, if you talk to people working @ SAP (i can speak for Germany only) they are all very happy working there.

Everyone has their war stories (god - did anyone else go rampup with MDM 5.5?), but generally SAP products match the hype, even if sometimes this takes time. You seem quite happy with the ABAP stack as it now stands but when R/3 replaced R/2 that was hardly a seamless transition - do you remember the pain?

Oh yes - I remember - indeed. But: at that time we never had problems or issues with the support, people didn´t need to forward messages to N components or get in contact with an M number of other people before they got an idea what a problem was.

I just think that we, as customers, pay money for something and I´m not disposed to accept everything "as is" just because "SAP is so big" or "SAP is slow". They put products on the market, customers pay for it so they, the customers, have the right to express their opinions and share them, being it positive or negative, no?

Markus

Hi Markus,

Yes - we did but the reason for that was not marketing. The reason is on one side "historical" (due to our R/2 past) and the lack of real good alternatives.

So in fact this is the fault of Oracle, not of SAP... I say that with a smiley, but you could argue that due to lack of strong competition, SAP have been allowed to get away with less than bullet proof support for their new technologies.

You can´t (or should I say you shouldn´t) put any software on the market if you don´t have the support ready (which means people, tools and knowledge).

I'd challenge this. There is a price to be paid for innovation. SAP are completely reengineering their technical landscape, partly due to strong demand from their customer base. I think savvy customers recognise this and adopt one of two strategies. Go bleeding edge and get in first with new technologies in specific areas if they feel will give them a competitive advantage (knowing that stability and support may be compromised), or sit back and wait, and let other customers iron out all the stability and support issues.

You can point the finger at SAP, but they are responding to customer demand, and I think that customers need to go into new product platform decisions with eyes wide open.

 An OSS call with Java still takes at least the double amount of time than the same on ABAP and still customers are not enabled to "help themselves" because knowledge transfer doesn´t take place.

Having made the points above, I acknowledge that I have experienced this also. Not specifically for the Java stack, but as the SAP landscape has grown more complex, issues that cross product boundries (ERP - XI - MDM for example) have become very lengthy to resolve through the SAP support process. It seems to be that the problem gets passed around from one group to another as there is no one owner - this is the classic silo effect, vertical channels of expertise where nobody knows what is happening outside their channel. With the introduction of SOA I can see this only getting worse.

What seems to be needed is solution based support experts who cross system boundries, linking up the technical experts in each area as required.

Oh yes - I remember - indeed. But: at that time we never had problems or issues with the support, people didn´t need to forward messages to N components or get in contact with an M number of other people before they got an idea what a problem was.

As I was saying above, the solution landscape from SAP has become more complex, and their support framework has not adapted well enough to deal with this yet.

I just think that we, as customers, pay money for something and I´m not disposed to accept everything "as is" just because "SAP is so big" or "SAP is slow". They put products on the market, customers pay for it so they, the customers, have the right to express their opinions and share them, being it positive or negative, no?

Yes, but didn't you get your point across after the first few posts?

Brad

So in fact this is the fault of Oracle, not of SAP... I say that with a smiley, but you could argue that due to lack of strong competition, SAP have been allowed to get away with less than bullet proof support for their new technologies.

Well - I know a anecdote where the reason for SAP starting with Java was an Oracle advertising putting technologies face-to-face (speaking of "ancient COBOL like language").

I'd challenge this. There is a price to be paid for innovation. SAP are completely reengineering their technical landscape, partly due to strong demand from their customer base. I think savvy customers recognise this and adopt one of two strategies. Go bleeding edge and get in first with new technologies in specific areas if they feel will give them a competitive advantage (knowing that stability and support may be compromised), or sit back and wait, and let other customers iron out all the stability and support issues.

I partially agree with you. Partially one, because to some extent customers are urged to use the new technologies (just as example 4.6C ESS vs. ERP xSS). Running out of maintenance and being in pressure to upgrade doesn´t offer much alternatives...

You can point the finger at SAP, but they are responding to customer demand, and I think that customers need to go into new product platform decisions with eyes wide open.

They are responding - and I´m not saying that they are not - it´s just too slow...

<...>

What seems to be needed is solution based support experts who cross system boundries, linking up the technical experts in each area as required.

Definitely.

Another problem in that area is the fact, that the complexity is alleged to be hidden behind nice frontends. "Usually" you click on a button and it turns green. If it does not, you´re lost. You have to open a call because since it´s nowhere documented, what is really happening when clicking on that button, you´re totally lost. In many areas you don´t even know, if the error is happening on the ABAP or Java or network or database or <insert-whatever-here> point. This makes OSS calls even longer because you can´t pick up necessary information together to attach them/explain. All you can do is to tell "I click on that button and it turned red".

As I was saying above, the solution landscape from SAP has become more complex, and their support framework has not adapted well enough to deal with this yet.

"Not yet"? Well - EP is out now for quite some time and I don´t have the impression, that someone is doing things here to "keep up".

Yes, but didn't you get your point across after the first few posts?

You consider me being a motor mouth?

Markus

Hi Markus,

I partially agree with you. Partially one, because to some extent customers are urged to use the new technologies (just as example 4.6C ESS vs. ERP xSS). Running out of maintenance and being in pressure to upgrade doesn´t offer much alternatives...

Good point.

"Not yet"? Well - EP is out now for quite some time and I don´t have the impression, that someone is doing things here to "keep up".

Good point.

You consider me being a motor mouth?

Good point.

Brad

moving to a new platform

I'd argue that they just bolt more stuff on. Because they're an application provider as well, it means that they have to support the old code they wrote as well, there's no business benefit in rewriting it if the net result is still the same. Eg if they were solely a platform provider, tables with header lines would be defunct. The breadth of the ABAP language now is getting ridiculous, especially if you work in an environment where there are no controls on what you can and can't code 😛

One problem is that instead of creating established development tools, SAP tends to hook into whatever is flavour of the month. An Internet front end written in dialog/ITS five years ago, now needs to be rewritten ( going to be in BSP) and will probably need to be re-written in whatever else in five years time.

Whilst on the subject of re-do, there was no migration path from XI 2.0 to XI 3.0, it was a case of rewriting all your interfaces on the later version. 😛

You consider me being a motor mouth?

> Good point.

> Brad

Uff... ok... my bad

Markus

> One problem is that instead of creating established development tools, SAP tends to hook into whatever is flavour of the month. An Internet front end written in dialog/ITS five years ago, now needs to be rewritten ( going to be in BSP) and will probably need to be re-written in whatever else in five years time.

BSP? That is ANCIENT - it will be rewritten in Webdynpro ABAP! )

> Whilst on the subject of re-do, there was no migration path from XI 2.0 to XI 3.0, it was a case of rewriting all your interfaces on the later version. 😛

Yes - same is true for CRM 2.0B to CRM 3.x - new implementation.

Markus

Markus,

You forget one point about the CRM version change. CRM software is more of "template" that you change than a pre-delivered solution. This statement may not ring true for CRM 2007, but those releases it was the case. I think there was a comment about SAP CRM from customer that I read recently that put things properly in perspective:

SAP CRM is like receiving a set of lego blocks, than you then have to assemble the pieces together

Let's face though, the transition away from the ITS was probably a good thing, and I'm a reformed ITS developer telling you this. I'm still fascinated by the fact that new CRM release is still written in WD-BSP instead of WDA. If you don't know what WD-BSP is, it is basically an MVC version of BSP that "emulates" web dynpro concepts without being web dynpro. Since it is still ABAP, you can easily troubleshoot errors just like you can with normal BSP pages.

Take care,

Stephen

You forget one point about the CRM version change. CRM software is more of "template" that you change than a pre-delivered solution. This statement may not ring true for CRM 2007, but those releases it was the case. I think there was a comment about SAP CRM from customer that I read recently that put things properly in perspective:

SAP CRM is like receiving a set of lego blocks, than you then have to assemble the pieces together

I don´t attack that - I just say that there should be a migration/upgrade path. Starting from scratch may be a GoodThing(TM) for new customers and new implementations but for those customers who invented already a lot of time (and hence money) in a software version. If that protection of investment is no more given (for whatever reason) one should refrain from implementations.

Let's face though, the transition away from the ITS was probably a good thing, and I'm a reformed ITS developer telling you this. I'm still fascinated by the fact that new CRM release is still written in WD-BSP instead of WDA. If you don't know what WD-BSP is, it is basically an MVC version of BSP that "emulates" web dynpro concepts without being web dynpro. Since it is still ABAP, you can easily troubleshoot errors just like you can with normal BSP pages.

This might be because of EEWB he? Otherwise the EEWB would have needed to be rewritten...

Markus

Markus,

You are right about migration paths. All the customers who will go from CRM 4.0/5.0 PCUI will have to redo their screen customization. The only migration path is manual work and effort with no tool to take care of it. It's not as bad though per se like an Internet Sales implementation. The good part is that your core business process configuration still remains the same at the end of data(with some extra features added).

As far as the EEWB it might be good thing if the tool got re-written. Since you and myself functioned on pre-EEWB CRM, you understand that the tool had some limitations, and caused bad data modeling for certain types of extensions. At least with CRM they have only been switching UI's for non-ISA releases about every other major version. However part of that is driven by the fact that customer base has never like the UI for CRM from the start. One bonus is that SAP has gradually been eliminating the boxes needed in a CRM landscape. The CRM 2007 landscape looks a lot simpler than a CRM 2.0C/3.0/4.0 landscape.

Take care,

Stephen

> You are right about migration paths. All the customers who will go from CRM 4.0/5.0 PCUI will have to redo their screen customization. The only migration path is manual work and effort with no tool to take care of it. It's not as bad though per se like an Internet Sales implementation. The good part is that your core business process configuration still remains the same at the end of data(with some extra features added).

...and that is preventing us from upgrading - or even consider doing so until the end of maintenance of CRM 5.0.

I will never understand why on one side enhancement packages and the switch framework are hyped (enh1 - 3 for ERP, coming enh1 for NW 7.0) and on the other side doing the opposite by introducing a completely new half-hearted implementation of yet-another-web-framework...

<...>

> At least with CRM they have only been switching UI's for non-ISA releases about every other major version.

oh yes...

> However part of that is driven by the fact that customer base has never like the UI for CRM from the start.

Do you like CRMD_ORDER?

> One bonus is that SAP has gradually been eliminating the boxes needed in a CRM landscape. The CRM 2007 landscape looks a lot simpler than a CRM 2.0C/3.0/4.0 landscape.

That is true too - definitely - and I highly appreciate that!

 
Iam hearing the rumors of JAVA developers dominating the ABAPers
any comments.

I think that whatever consenting adults do in private is their own business.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

This actually is a hopeful sign in reversing the trend to "Offshoring" in India and elswhere.

Modern computer systems rely more amd more on people understanding the basic Business Processes involved. Computer Programming per se is becoming less and less important in this environment. Of course some basic skills in programming will remain important and such facilities such as BASIS will still require specialized skills.

However the days of "The Basic Abapper" really are numbered.

To check this out just look at some of the total "Interview Monkey" questions that appear on the basic ABAP Forums. You get guys still asking questions on dveloping report lists using really OLD and OBSOLETE technology such as using non OO methods ( SLIS Functions for example) and asking people to write their whole application for them.

Most reporting these days can really be done in a few lines of code using dynamic tables, dynamic field catalogs and a decent OO class call to SAP's ALV lists which shouldn't take ANYBODY more than a couple of hours to code any more - I've posted MANY examples of "generalized OO ALV methods" on the forums.

JAVA is relatively similar as well in the OO area.

Web / Internet / Portal technolgy is another area which DOES require expertise but guys involved in this stuff are not "typical Abappers".

If you are an "Abapper" reading this -- just say you've enjoyed it while it lasted but the writing is on the wall for the long term future.

Either get into Basis / Web technology or switch to business functional areas.

Whether it's ABAP, JAVA or "Micky Mouse" a programming language is just that.

How many people now still use old IBM mainframe Assembler, PL/1 or Cobol anymore --even though these languages were absolutely the tops in the 1970's - 1980's.

Those who wish to say purely in support probably will last a bit longer but is this an area you want to stay in long term.

Cheers

Jimbo

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

I can think of at least one company with a $40 billion turnover still using COBOL and mainframes.

The problem always was whilst newer technologies offered easy development and greater integration and flexibility, the mainframe excelled in the key area of number crunching. One of several reasons for the success of SAP is the fact that it genuinely can go toe-to-toe with a mainframe. Silos of information, but with the processing power to exploit it. When faced a business requirement to say process 400 stores worth of sales in 3 hours, previously most firms found that the mainframe was the only cost-effective solution.

Good ABAPers will always be in demand. The SAP market is growing all the time, especially the SME market, and a lot of firms are struggling to fill vacancies.

If I were offered a JAVA developer, I wouldn't be able to find a use for them within our SAP environment (since our integration product is IBM Websphere 😛 )


 One of several reasons for the success of SAP is the fact that it genuinely can go toe-to-toe with a mainframe.

Software vs hardware, the comparison's meaningless. And you can (or could) run SAP <I>on</I> a mainframe.

The sky is falling !!!!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

if not the sky, something [else|http://www.presstv.ir/detail.aspx?id=40579&sectionid=3510203] might fall...

~Suresh

Ask a Question