Ditch WebSphere and .NET for NetWeaver?
My company has a significant investment in both WebSphere and .NET development, though we will take delivery of NetWeaver as part of our upgrade to MySAP Business Suite later this year. What should we do about these other technologies? The investment in them is important, and we're seeing some positive results for our business users, but the sales rep is pushing us hard to standardize on NetWeaver.

    Requires Free Membership to View

    When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSAP.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSAP.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Don't ditch .NET or WebSphere just to make your SAP sales rep happy. WebSphere and .NET compatibility are major goals of SAP – the public and private commitments are significant by all parties. What will have to happen eventually is a strategic decision to maintain a mixed-technology shop or look into migrating .NET and WebSphere development over to NetWeaver. But the best thing to do in the short run is work on implementing NetWeaver for MySAP Business Suite and getting familiar with its capabilities, while maintaining your on-going non-SAP projects. Let the decision be made a little down the road when you know more about NetWeaver and SAP (and IBM and Microsoft) know a little more about their respective interoperability requirements.

This was first published in October 2004