SAP Tells Devs to Focus on Business, not Specs

Discussions

News: SAP Tells Devs to Focus on Business, not Specs

  1. SAP is warning us all that we currently care too much about the standards that we work with and not the business. They are telling us four things: Set aside Java/J2EE portability concerns; The JCP won't be able to give you the "next" Java career map; Focus on "portable data" not just portable code; and take a fresh look at persistence (Base it on business needs, not just language needs).

    Are these guys right? Are we ignoring business needs? I don't think so...
    Enterprise software maker SAP has some strong advice for Java/J2EE developers concerned about outsourcing: Focus your energies on your company's business problems -- and not slow-moving Java standards. Integration Developer News spoke with SAP's chief standards-watcher, Michael Bechauf, who offers Java/J2EE devs four (4) keys for how to find the best enterprise dev career opps in the coming two years. (WARNING: Some may find these controversial.)
    Read more in SAP Tells Devs to Focus on Business, not Specs

    Threaded Messages (48)

  2. Focus on Business?[ Go to top ]

    "I would argue that [Java] portability right now is already sacrificed."

    Since many years back, yes. Choosing a Big J2EE EJB server locks you in to that vendor (poor souls). How long shall this Urban Myth about J2EE compatibility endure?

    "To Bechauf, the rush of JCP activity is a "mad attempt" to fend off Microsoft's assault on the server side of computing (via .NET, BizTalk and other platform upgrades)."

    Is there any rush of JCP activity? Where is it?

    Regards
    Rolf Tollerud
  3. Focus on Business?[ Go to top ]

    "I would argue that [Java] portability right now is already sacrificed."Since many years back, yes. Choosing a Big J2EE EJB server locks you in to that vendor (poor souls). How long shall this Urban Myth about J2EE compatibility endure?"
    previsible and boring
  4. Focus on Business?[ Go to top ]

    How long shall this Urban Myth about J2EE compatibility endure?
    Probably for at least as long as I am able to easily move applications back and forth between WLS and JBoss.
  5. I am beginning to enjoy this. In what category shall we place this? With the people that defended "EJB 1.0 Entity beans", or with the ones that ridiculed "stateless web applications" or with the ones that called the authors of light-weight frameworks for "code-clowns" or with the ones that always do "select * from" and do not know how to save a data field?

    Corby:"Probably for at least as long as I am able to easily move applications back and forth between WLS and JBoss".

    Viable of course if your application is something like "hello world" or a simple forum.. But let us suppose that all and one, even complicated commercial applications is easily moved between different Java EJB Servers, as an "academic question".

    How easy is then to move it to a framework like Spring? Isn't a refresh of TSS site overdue? Why not move it to a light-weight framework so everybody can first hand experience the faster response and better uptime? To escape a technology that are down nearly seven hours of time per week, or worse according to Wily?

    TSS upptime

    So you are not only locked into a particular EJB server but you are also locked into the overpriced and overly complex Java EJB Server world :(

    Regards
    Rolf Tollerud
  6. Rolf,
    try to learn serious things. I think clever man have no time to search this kind of articles on inet. If you need to find something more stupid try to search "java sucks" on google (http://www.google.com). As I understand it is writen for idiots, nonsences about j2ee in text suraunded by cool pictures about .NET.
    Do not waste my time please.
  7. Hmm.. So you compare a respected company as Wily Technology that has received,

    Investors' Choice Awards
    http://www.businesswire.com/webbox/bw.060704/241596025.htm, and

    Wily Technology Named to Second-Annual AlwaysOn™ List of Top 100 Private Companies
    http://www.wilytech.com/news/releases/040708.html

    with a google search of "java sucks"? Interesting.

    Anyway TSS uptime is what it is (93.59 this week), no squirmy excuses in the world can change that.

    Regards
    Rolf Tollerud
  8. It is not about your, it is about .NET marketing strategy at this time, probably you are very clever man, but you do not want to talk about serious things for some reason. I am not surprised about statistics, j2ee is too simple and webmasters started to use it, I am sure PHP is better for webmasters, but they want "Big Thing" for some reason, It is not JAVA problem.
  9. webmasters?[ Go to top ]

    I am not at all into NET marketing, I can even concede that Java actually has the advantage of .NET at this moment in time. (with Spring on the server and SWT on the client).

    I am outraged on the other hand at the "Big Java EJB Server" that is the biggest hoax in IT history IMO, and in addition accompanied with the superior smirk of the self-appointed "computer scientist". If you go out with such as high profile and show such results you must suffer the consequences of ridicule. It is not my fault; it is the way of the world.

    Jouzas:"I am sure PHP is better for webmasters."

    I hope you are not calling Dion and his team for "webmasters"? They have a long and successful carrier as consultant’s consultants, as well as Java books etc, etc under their belts. If this competence is not enough no-one else can do it within reasonable cost.

    Regards
    Rolf Tollerud
  10. webmasters?[ Go to top ]

    Jouzas:"I am sure PHP is better for webmasters."I hope you are not calling Dion and his team for "webmasters"? They have a long and successful carrier as consultant’s consultants, as well as Java books etc, etc under their belts. If this competence is not enough no-one else can do it within reasonable cost.RegardsRolf Tollerud
    I do not have any problems with j2ee, if book writers have problems with j2ee uptime then I recommend to try PHP. See Hibernate forum, I have never saw better forum implementation, it has no uptime problems, I am this forum user have never saw any problems, you ask forum moderator about statistics, it is implemented with PHP.
  11. webmasters?[ Go to top ]

    BTW it is possible to find free hosting for homepage if it is implemented with PHP, it is very important aspect for homepage.
    I understand why webmastes like j2ee, it very simple, object oriented language, safe, secure and fast, but it needs a lot of knowlege and it is too expensive for homepages, "simple to use" can become your enemy, it has many meanings. PHP is the best for webmasters in "simple to use" terms. I have PHP master certicate too, it takes two weeks to become expert and PHP master, there are a lot good use cases for this technology and you can find a lot of good examples.
  12. ... with the ones that ridiculed "stateless web applications" or with the ones that called the authors of light-weight frameworks for "code-clowns"
    Ah, the lightweight framework sneaks in again. The authors of the lightweight frameworks are at the present time more and more leaving the "light weight track", adding (XA-) transactions, persistence, AOP and what not to their original simple configuration engines. In due course they will have come round full circle with the next huge and hard to handle toolset. Striving for simplicity is well meaning but is not leading you anywhere if the problem is not simple.

    Take "SOAP", a nice light weight, easy to use, easy to understand RPC like mechanism - That's what it was. Now with SOAP, WS-Security, BPEL, UDDI, WS-Transaction .... it has become a specification monster that still does not deliver what Corba did 5 years ago. At least CORBA has language bindings, argh.
  13. lightweight is for modular[ Go to top ]

    Well I see lightweight framework as a way to give you the choice to select which modules you want to use (just take a look at spring or picocontainer, they give you the freedom to use jdo or hibernate, struts or webwork and so much more). The core itself IS lightweight. Additional modules add weights but no more than necessery.
    As I see SAP, they (as IBM, Microsoft, BEA ...) would like you to push the whole stack of their softwares through your throat even if you only need 10%. Saying you don't need to care about standards is no surprise coming from a company pushing its own non or pseudo standard solution. Just marketing tactic : they'd love to lock users in their products. I really hope they will change their strategy because at the end it will be highly damageable for SAP users.
  14. J2EE Portability.[ Go to top ]

    How easy is then to move it to a framework like Spring?
    I'm not sure I get your point, unless you were just being a wise guy. It isn't really comparing apples to apples to say that since changing your persistence layer to a new framework may be hard (or at least a lot of work), that Java and J2EE isn't portable.

    Personally, I find it relatively easy to code to the J2EE specs for most of the apps I've worked on. That makes the application pretty portable. You'll have to take my word that I've worked on real enterprise applications.

    Drag and drop portable? Well no, but nobody ever claimed that - at least in recent years. But many times the work solely involves tuning the new server and tweaking deployment descriptors - not changing the code base. Isn't that portable enough? That I can move to a new platform without recompiling? Can you do that with another language/platform with a similar functionality base?

    Sometimes one or two platform-specific helper classes have to be rewritten, but those are usually just startup classes or similar. Maybe that is enough for people to say portability is a myth, but I think that is just being stupid, political, or both.

    Although, I've got to say many interesting and useful WAR projects are drag & drop portable (VQWiki anyone) so there is proof that J2EE portability isn't a myth.
  15. Focus on Business?[ Go to top ]

    How long shall this Urban Myth about J2EE compatibility endure?
    Probably for at least as long as I am able to easily move applications back and forth between WLS and JBoss.
    You're right. To me, J2EE has never been more portable than now. Every new J2EE release reduces portability issues. The real problem was that J2EE vendors were pushing the technology on their side to be better than the others. This is changing because, now, they have to reduce the price of their expensive servers (thanks to open-source J2EE app servers) and therefore they've less money to waste. To me, they've already lost the app server market, and they probably knows it (why are they trying to move from app servers to portal servers ? The "added value" of the portal server and the pre-built portlets included with it is the only way to justify expensive prices over free app servers).
  16. Focus on Business?[ Go to top ]

    SAP?

    Oh yeah, they that crappy software the bean counters at my company make us use to enter our time. Well since they have soo much influence over the JCP and the Java community, I guess I'll listen to their advice...

    :|

    SAP, now you know why nobody went to your Java One booth and why no one takes you seriously.

    Oh and Rolf, while vendor lock in may be a "feature" of IBM WAS, portablility is a feature of most others, like, WLS, JBoss and Oracle. Nice straw man...
  17. Focus on Business?[ Go to top ]

    I understand his point, I think...

    If you want to make a lot of money then get to know your company and the business. That is good advise? Developers are a special group of people. We are motivated by different things than a VP is! One such thing is code that works. I have had to integrate into SAP, thier JDBC drivers suck! Yo uneed to gain our respect before pulling us over into the dark side of business :)
  18. Bingo![ Go to top ]

    One such thing is code that works. I have had to integrate into SAP, thier JDBC drivers suck! Yo uneed to gain our respect before pulling us over into the dark side of business :)
    Secondary to your original point about getting to know your customer...knowing how to integrate systems that don't work so well is a better skill than knowing when Groovy would pass through the JSR process.

    No one in business really cares about that kind of stuff...they just want their systems to talk to each other. Unless you're developing software that is sold or open sourced for installation...your developing software to meet business needs.

    So, for example, why would I care about converting my project to use Tapestry (first thing that came to mind...not saying anything about the technology) as opposed to a pure JSP/servlet approach that is currently implemented. The current approach works, is successful, and although the maintenance may be annoying, has not been considered to be too costly by management. When they decide to look for a cheaper solution, there will be two things to do...pick the solution, and migrate. The more difficult of the two, and highly less glamorous in terms of cool factor is migration. But you'll earn a lot more points in being successful at a migration in most businesses, than being a developer sitting in a corner whining that we're stuck using J2SE 1.3.1 and not up on 1.5....errrr...5.0
  19. Bingo![ Go to top ]

    Unless you're developing software that is sold or open sourced for installation...your developing software to meet business needs.
    Yes, you are right. I work with stock exange data and with ebanking, but one of our customers sells pictures online. Picture is very important data for my customer, it is money and it means this data is mission-critcal for me too, customers do not care about our toys and trasparence.
  20. Bingo![ Go to top ]

    You are right by all means, but it is still nice to grudge about the new Giant Enterprise solutions from the technical perspective, even though one will have to integrate it and support it.

    Also, business folks many times do not know waht they are getting into and even if their systems talk to each other and do whatever other fancy business requirements based features the product does, they inadvertantly start caring about other issues that pop up, but than as you said - they migrate. Overall though, most of the companies tend to choose a well-branded out-of-the-box working solution, and no matter how ugly such solution is on the inside, well, as long as it works on the outside - everybody is happy.

    Sincerely,

    Artem D. Yegorov
  21. Bingo![ Go to top ]

    Overall though, most of the companies tend to choose a well-branded out-of-the-box working solution, and no matter how ugly such solution is on the inside, well, as long as it works on the outside - everybody is happy.
    Actually, I think you're giving SAP, Peoplesoft (where my expience is), Oracle, etc. too much credit. They work out of the box...but for generic company X. What ends up happening is that they get hacked, modified, etc. to meet those business needs. Which is what makes the migrations so difficult. The reason the product gets sold is because of great sales staff who sells to business people who are looking for the holy grail. Not every company is as brave as WalMart, who told these vendors that they would not alter their business model to meet what the product delivered...and continued to build in house solutions instead. Somewhere along the line the business guys think these solutions will offer less maintenance.

    The more I work, the more I realize I'm like a hot rod mechanic...tuning, fixing, tweaking, to get the most out of the car I bought from the dealer...rather than trying to build a car from a bunch of off the shelf components.
  22. Bingo![ Go to top ]

    Actually, I think you're giving SAP, Peoplesoft (where my expience is), Oracle, etc. too much credit
    No credit given, I actually hate how much time it takes to implement a well-oiled SAP or other ERP/CRM system. It works great...well, after a year or two of integrating, fixing, tweking and all...and several million dollars down the drain...and 20 people at least supporting it...But in many cases that works for the business folks, and they are the ones, again in many cases, who directly affect your paycheck, so we may not agree, but tough luck, we got to do it anyways...
    The more I work, the more I realize I'm like a hot rod mechanic...tuning, fixing, tweaking, to get the most out of the car I bought from the dealer...rather than trying to build a car from a bunch of off the shelf components.
    I went from a Utility company ro a Software development company, just because of that feeling. I get to build stuff, not maintain and fix.
  23. Of course a developer needs to be in touch with and meet the needs of the business.

    But you also have to be writing code that you can maintain and reuse - to reduce the development lifecycle.

    You can write your sloppy spaghetti code to meet the deadlines, but in the long run, its going to cost you.
  24. Businesses prefer Spaghetti Code?[ Go to top ]

    Of course a developer needs to be in touch with and meet the needs of the business.But you also have to be writing code that you can maintain and reuse - to reduce the development lifecycle.You can write your sloppy spaghetti code to meet the deadlines, but in the long run, its going to cost you.
    Well in principle I can't agree more, but in reality it's not as simple as that. In a project I worked on, my employer was bidding for a government project and had to get the site up and running by a deadline or they'd lose a contract worth of millions. That plus the ever changing requirements from the government people left us on a tight if not impossible schedule. Guess what, we just had to put aside all our "geek pride" or the "architectural correctness" and throw in whatever hacks and corner cutting to just make it working, because we wouldn't have "the long run" otherwise.
  25. Businesses prefer Spaghetti Code?[ Go to top ]

    Guess what, we just had to put aside all our "geek pride" or the "architectural correctness" and throw in whatever hacks and corner cutting to just make it working, because we wouldn't have "the long run" otherwise.
    Which I guess explains this - "GAO: Pentagon IT mismanagement wastes billions " http://www.computerworld.com/managementtopics/management/itspending/story/0,10801,94392,00.html
  26. Businesses prefer Spaghetti Code?[ Go to top ]

    Which I guess explains this - "GAO: Pentagon IT mismanagement wastes billions " http://www.computerworld.com/managementtopics/management/itspending/story/0,10801,94392,00.html
    LOL, yeah I guess it does - in a general way anyway. Don't get me wrong, I am not defending the practice, but merely pointing out that business customers usually consider factors more than the technical soundness of a system. Would they be willing to sacrifice immediate market opportunities for long-term maintenability? Probably not.
  27. SAP- legacy vs. J2EE dilema[ Go to top ]

    <blockqoute>
    "We follow standards and specs where possible, but we never can lose focus on our value proposition -- and that is to let the application developer focus on what the business application task requires."</blockqoute>
    Guess the concuding parah in the article summarizes (and contardicts the title) the reality. Following standards where possible is the mantra. And in pure J2EE environments (which would be most ground-up biz apps) this is very much possible- any biz need (including "portable" data) can be servcied within the standards. Now SAP is by no means a pure-J2EE enviroment- with its huge pre-J2EE legacy residing in its ABAP bowels. This by no means could be made portable.

    So bechauf is right, in that- the new j2EE parts of SAP will be portable. And the old ABAP (bulk of SAP?) will NOT be portable! But fortunately, most J2EE apps today dont have the same dilema! :-)

    Cheers,
    Ramesh
  28. I think they are right, data and transactions are more important for business than object caches and dynamic OO queries. I see a lot of populism ("easy to use") and ER model ignorance at this time. I think it is better not to fight with RDBMS and SQL, learn it.
  29. 50/50

    50% business / 50% techology
  30. Not surprised[ Go to top ]

    Hmmm of course SAP is going to make a statement like this, hell I wouldn't be surprised if BEA would make the same statement (that is before Beahive became open source).

    Vendor lock-in is in SAP's (and most vendors') interests, not mine. I like using things that adhere to open standards.
  31. the end of an evolution[ Go to top ]

    I do not think that it is possible to refine the frameworks much any more there will only be minor improvements. Take for instance as an analogy Hi-Fi amplifiers. For many years there was a fierce competition to have as flat frequency line as possible over the 20-20.000 area. But once they that was perfected it was finished! No idea to extend beyond that because the human can not hear higher frequencies..

    In the future it will be more important what business areas you have as your experience, Bank-finance, CMS, CRM, etc. Take Richard Öberg for instance even if without question he is a very good Java developer I think his main asset now is as one of the world leading specialists on CMS.

    Regards
    Rolf Tollerud
  32. Missing the best point[ Go to top ]

    While trying to point out flaws with this argument, I think some here have missed the point.

    The majority of developers don't live in a world where open standards are the norm. They live in a world where the customer...the business...has a need, and already has an existing system to migrate.

    The key that I pulled out of the whole argument, is that you need to think less about how to make that system run on open standards, but to think about what the customer needs, and how you can migrate them to a system that will perform those needs.

    For example, if the open standard for financial transactions exists, but it does not meet the business needs, what do you do? You extend it...hence breaking the standard...or you create something from scratch. Standards mean nothing if they do not meet the needs of the business.
  33. Missing the Real point[ Go to top ]

    Rough translation of this article based on skimming:

    1. SAP has some kind of persistence widget they want to sell you.
    2. Their technology breaks some accepted java standard.
    3. Their technology was rejected by some committee of stuffed shirts in the JCP.
    4. They want you to buy it anyway.

    I'm not saying you should or shouldn't buy it, whatever it is -- Just that you should know a sales pitch when you see one.

    It's not terrible advice to focus on the concerns of the MBAs upstairs who sign our paychecks. Whether this implies that buying their persistence widget is a good idea is... well... an excersize for the reader.
  34. Missing the Real point[ Go to top ]

    Yes, everything is about money and I am sure SAP sells some sofware too, but I think statements made by SAP to sell sofware are good.
  35. Missing the Real point[ Go to top ]

    Rough translation of this article based on skimming:1. SAP has some kind of persistence widget they want to sell you.2. Their technology breaks some accepted java standard.3. Their technology was rejected by some committee of stuffed shirts in the JCP.4. They want you to buy it anyway.I'm not saying you should or shouldn't buy it, whatever it is -- Just that you should know a sales pitch when you see one.It's not terrible advice to focus on the concerns of the MBAs upstairs who sign our paychecks. Whether this implies that buying their persistence widget is a good idea is... well... an excersize for the reader.
    It's even worse than this. SAP is purveying a message straight to execs: Your technical staff are idiots. They keep trying to push your company down this straight jacket road of "java standards". They don't really have your business as their first priority but are more focused on enhancing their resumes. Come let us show you our much more pragmatic products. Pay no attention to your IT nerds and their mumblings and accusations of self-serving vendor lock-in. That's not what we're about - we only care about helping you solve your business problems.

    When standards tend to force matters in a direction toward commoditization it is only to be expected that there would be vendors that directly assail standards for that very reason.
  36. Missing the Real point[ Go to top ]

    Rough translation of this article based on skimming:
    1. SAP has some kind of persistence widget they want to sell you.
    2. Their technology breaks some accepted java standard.
    3. Their technology was rejected by some committee of stuffed shirts in the JCP.
    4. They want you to buy it anyway.

    I'm not saying you should or shouldn't buy it, whatever it is -- Just that you should know a sales pitch when you see one.It's not terrible advice to focus on the concerns of the MBAs upstairs who sign our paychecks. Whether this implies that buying their persistence widget is a good idea is... well... an excersize for the reader.
    I don't know how many people here are actually involved in the build/buy decision. Is everyone here the CTO of their org? I know that I've got "technical" management that is not technical at all. You hope they understand the translation to management speak that you give them that says, hey let's build it. Some of us don't even get to make that argument. You have to hope the right decision is made...but it's a 50/50 shot that it will be.

    Throw out the sales pitch in the article, and there is a lot to be learned there from a we're going to buy perspective.

    If you're going to build, you still have questions:

    When I get a decision that is build not buy...is going with an accepted open standard a good or a bad thing for my business?
    Will it provide competitive advantage, or just make it easier for others to copy?
    Does the open standard even meet my business needs? Is it worth it to extend, or hack, or should I just roll my own?

    There are many other questions to ask...but to advance in your organization, you need to be able to answer those kinds of questions in a business perspective....otherwise, you're probably going to be inline to be outsourced in the next 10 years.
  37. We've got a pending integration of their Netweaver platform at my company.

    That is their Java direction, but even if they say that they are business oriented, that does not seem to be true, judging by how badly designed and architected the product stack is.
    Check it out at http://www.sap.com/solutions/netweaver/

    As far as standards, well SAP is definitely going away from following a lot of standards (their WebAS is a good example of how an application server would take J2EE standards and specs and throw such out of the window), but their goal, as it looks like from several comments made in ther Netweaver's architect inteview, is to come up with a whole bunch of "SAP" standards where the Netweaver platform becomes a competitor to J2EE and .NET. How about that?!

    So the way SAP thinks about the business is described in their latest work in XI (one of the products in the netweare stack for transactional data mapping and translation) where instead of writing reusable, standard's driven code, a quality management interface, pluggable architecture and etc., their big thing is that they spent, quoting one of the guys in the presentation they made at our company, 1 billion $ on reasearch every year to figure out all of the possible mapping templates and ship such with XI and to make a claim of being able to fit any organization with a subset of mappings/configurations out of a gazillion availble. So it is a new way in technology for them - quality is replaced by quantity. I hope their advice would never be followed.

    They do not like standards, but all of their platform going forward is and will be based on Eclipse of IDE, lot's of WebSphere influence for WebAS base and WebMethods older version of BusinessConnector for XI. All of those of course tweaked and changed, but none the better. The going versions of the original products and their vendors do follow Java standards to a reasonable extent, but I guess SAP knows better..., right?!

    Sincerely,

    Artem D. Yegorov
  38. the chicken tells the hen[ Go to top ]

    So you criticize SAP for that they doesn't rapidly enough adjust to the Sun so called "standards" of the week?

    SAP is the largest provider of enterprise applications software in the world, more than twice as big anyone else. Its ABAB technology existed long before Java even was an idea in Goslings head. That SAP strives to integrate with both J2EE and .NET can be seen here. It is Sun that doesn't care about existing technology from "small" companies like MS & SAP. It is a sickness called "hubris". I think they are recovering from lately, though.

    Regards
    Rolf Tollerud
  39. the chicken tells the hen[ Go to top ]

    SAP is the largest provider of enterprise applications software in the world
    A little exaggeration, is it not? And the size of SAP does not make it the leader in the technology, especially where SAP clung to ABAP like monkey to the banana, which was good for its time, but not when the business goals became bigger and more comprehensive and where ABAP developer's cannot adapt to the object-oriented world.

    My company was big on ABAP and that is the main problem that we have now trying to migrate those miles and miles of ABAP code with no reuse, standards or whasoever into to a more cleaner and smaller Java-based structure.
    ASM existed way before ABAP and so what? Are you going to defend that to?
    It is Sun that doesn't care about existing technology from "small" companies like MS & SAP
    As well as them, mostly MS, do not care about SUN. Java came from SUN, so abide by SUN's specs and standards. The only way for Java to survive is for vendors and developer's community to follow a set of defined standards and such standards need to come from a single source - a comittee (JCP in this case).

    From the link:
    Although it is possible to create purely Java-based applications from scratch, applications will most probably be based on mixed scenarios in the near future – where Java drives the frontend and ABAP still dominates the backend
    That statement alone diminishes Java's role in SAPs plans and reiterates their plan on keep on going with ABAP. Sure, let's vote for that and have ABAPJ or ABAP Server Pages. What is so bad about Java defining backend and front-end, well, there are numerous choices that integrate well with Java, but not with ABAP.

    Sincerely,

    Artem D. Yegorov
  40. Artem: "That statement alone diminishes Java's role in SAPs plans and reiterates their plan on keep on going with ABAP."

    It is not so easy for SAP to give up ABAP. As I understand they have made big chunks of the system in it!

    The thing here is that there is something that is called "customer satisfaction" or "the customer is always right". Something strange to those that wants all and everybody to adapt to Java instead of the other way around. It is very unwise not to keep a very good relation to SAP. Just a good advice! :) These rumblings from SAP are the first time I noticed any dissatisfaction from that direction. Could it be the beginning of something?

    Anyway today TSS is very fast and snappy. And the availability was 100%! Can it be that they have solved their problem? Shall be interesting to see what happens over the week-end.

    Regards
    Rolf Tollerud
  41. No argumetn there, jsut carping from the technical perspective. If you got SAP implemented, as we do, better follow their lead, as otherwise changing the whole process and architecture is going to be a tremendous amoun of time and money, which is not something that goes well with the business side of the world, expecially when everything is working fine from the customer's perspective.
  42. I have not completely read the article, but it seems, its a valid argument to focus on Business rather than specs.

    AFAIK, companies give more weightage to people who have exp. in particular industry than somebody who is upto date with so-and-so technologies.

    And 75% of the companies don't worry about portability. How many companies moved from WebLogic to WebSphere and vice-versa?

    And most of the time, I have been asked to utilise the capabilities of the App. Server even if it means tight vendor lock-in.
  43. I have not completely read the article, but it seems, its a valid argument to focus on Business rather than specs.AFAIK, companies give more weightage to people who have exp. in particular industry than somebody who is upto date with so-and-so technologies.And 75% of the companies don't worry about portability. How many companies moved from WebLogic to WebSphere and vice-versa?And most of the time, I have been asked to utilise the capabilities of the App. Server even if it means tight vendor lock-in.
    Yeah, I agree, most important thing in today's market is industry experience and business/domain knowledge.

    But in Bechauf's view this means locking yourself with SAP.(Atleast this is what i can understand from his interview). No language is going to solve all the business problem, thats why so many technologies exists there.

    And yes, there are issues with EJB/Data Persistence in J2EE. But picking up just that one issue and trying to push SAP stack seems very lame idea to me!
  44. And yes, there are issues with EJB/Data Persistence in J2EE. But picking up just that one issue and trying to push SAP stack seems very lame idea to me!
    Data is the most important thing for business, is not it. It is possible to drop any technology and reinvent a new one, but data lives longer. Database and data is the most important thing in most "enterprise" systems, it is possible to implement frontend with any tool, it is not very important, most of technologies die anyway.
  45. Data is the most important thing for business, is not it. It is possible to drop any technology and reinvent a new one, but data lives longer. Database and data is the most important thing in most "enterprise" systems, it is possible to implement frontend with any tool, it is not very important, most of technologies die anyway.
    No, I am not questioning the importance of data. I have doubts about how much SAP can succeed in selling their point just by concentrating on data persistence.(Though there are problems, still there are so many J2EE systems which does the data persistence).

    And by the way, I too believe understanding business buys you more than being upto date with cool technologies. (Its only my exp. need not be the same for everyone)

    And the article is not talking much about understanding business. It talks abt. how SAP did ABAP etc etc.
  46. Yes, this ABAP stuff is not important for business too.
  47. I don't share SAP's opinion on source portability. Coupling it with database independence, which most J2EE app server provide, is a big plus. My company has spent years of resources porting code from one platform to another. I think SAP should focus a little better on enterprise's business needs and take a look at where the real bang for the buck is, source portability, coupled with database independence, with O/R mapping becomming the norm.
  48. Sales pitch[ Go to top ]

    We have also their Netweaver and we ported BEA application to SAP WEB AS - that took only few days to have it running.
    I think their server is better than their marketing and I don't know why they say this about the standards, probably they want to
    sell much more things than only the J2EE server.

    Regards
  49. Sales pitch[ Go to top ]

    If I had only tried to sell our stuff, I did a pretty lousy job, having not even mentioned a product name in the interview. Yes, our warehouse and supply chain management applications are powered by our own J2EE server, but my main focus was to report about our experiences building J2EE applications in very large teams and lessons learned when it came to deploying and supporting these apps at many of our 20,000 customers.

    Building applications that work in such an environment is how we make our living, and we have been successful with it for many years. Taking all this experience and applying it to J2EE was an interesting challenge.

    Example: Our customers select the database vendor of their choice, so our apps need to work on any database. It’s impossible to test a huge application like CRM on any given database; the platform needs to make sure that application developers don’t need to worry when switching from one database vendor to another. Nothing in the J2EE spec says that apps need to work on any database and we all know that CMP is not the answer, so we implemented the JDBC, EJB, JDO spec in a way that our app developers don’t need to worry. So, no, there is no magic persistence widget, just an extension to industry standards.

    Another example: Given where J2EE is today, it is essential to come up with ways to boost application development productivity, let it be through declarative application frameworks, data binding or what have you. Sure, every vendor has its creative solutions to solve that problem and I am looking forward to the time when there is finally consensus how the ease-of-development problem can be solved in a way that is accepted throughout the community – we will support the standard when it comes out and will contribute our experience to the JCP to get there. Until then, an application vendor like SAP cannot wait. Whatever gets us developer productivity on top of the existing standards will be the key to our success as a vendor that builds large applications on top of J2EE.

    Looking a couple of years down the road, I wish that developers won’t have to worry any more about technology choices and migrating existing code towards new emerging standard specifications. Application developer productivity will be built into the J2EE platform, there will be commonly agreed productivity standards supported by all vendors and interoperability standards will clearly define what requirements a service-oriented architecture needs to fulfill. This will be the time when application developers can finally focus on solving business problems and the key to success will be an understanding of the business domain that your company is in.

    Until we get there, spending more time to understand the different technology choices and standards will be necessary. If it's 50:50 today, I hope that ratio will be significantly going towards the business side as new standards emerge.

    Hope that clarifies some of my points.

    -Michael