SAP and Openness at TechEd in Berlin
Even though this was my first time attending a TechEd (or any other SAP event for that matter), I decided to go against the “general advice” for first-time attendees, and chose not to make any plans or book sessions before I left. I went as a part of the ESME team, as a DemoJam speaker, as a blogger and as a Mentor. All of those combined didn’t leave me much time to hang around and be stunned, but instead left me feeling as if I had been in a wind tunnel for four days.
The official TechEd theme this year was “Connect, Collaborate and Co-Innovate” and when I saw this, all I could think was that this must be the right TechEd for me.
As part of the ESME team and as an SAP Mentor, I had already familiarized myself with these three words as SAP understands them during the last weeks and months leading up to the TechEd.
The journey started on Sunday on the Cluetrain from Frankfurt to Berlin.
This was the pre-pre day event, and as it turned out it set the conversation for the rest of the TechEd. For the first time I was participating in a discussion about openness and collaboration and what this means to SAP.
(On a small side note: The ride was definitely worth the small de-tour via Frankfurt, and I will definitely join next year too!)
This discussion continued on Community Day, where Darren Hague on short notice decided to do a session on “NetWeaver and open source”. During the next two days, the Mentors/bloggers had the opportunity to talk to Zia Yusuf and Hervé Couturier and in both these meetings the word “openness” was re-occuring.
Unfortunately I wasn’t able to participate in the meeting with Zia Yusuf as I was tied up in DemoJam preparations, but from what Dennis Howlett writes, Zia was listening intensely instead of arguing.
When I started working with SAP three years ago, I decided to only focus on new technology (ERP5.0 and up), as there already are enough consultants/programmers out there who cover older systems. During my initial trainings the NetWeaver platform was always pitched as an open technology platform, ideal for developing applications.
“SAP NetWeaver: Integrated, open and inclusive”
“SAP NetWeaver provides an open, flexible and adaptable platform that addresses the challenges of today’s IT infrastructures and tomorrow’s IT evolution.”
It didn’t take long however, for me to realize that SAP’s picture of what the words open and inclusive mean are slightly different than how I was used to view those words.
The only way one can develop applications on a NetWeaver platform today, is if you work in for a partner or a customer, who already have a license.
“SAP NetWeaver is a web-based, open integration and application platform that serves as the foundation for enterprise service-oriented architecture (enterprise SOA) and allows the integration and alignment of people, information, and business processes across business and technology boundaries. It utilizes open standards to enable integration with information and applications from almost any source or technology. SAP NetWeaver is the foundation of SAP Business Suite and SAP Business ByDesign, and also powers partner solutions and customer custom-built applications.”
Now what do you do, when the project you are working on, isn’t from either a partner or a customer?
This question first became a reality for me when I started working on the ESME project. ESME is a community-driven project and because most of those involved are passionate SAP’pers we wanted this solution to run on NetWeaver.
Little did we know when we started exactly how difficult it would be to actually find an instance for it to run on. The first version actually ran on a Tomcat server.
I have had many people asking me along the way, why we were making it so difficult for ourselves. Why wouldn’t we just use JBoss like “everyone” else?
Usually, my answer would be “because we are stubborn and stupid”.
The real reason however for going with SAP is that we have hopes things will change for the better.
The Mentor meeting with Hervé Couturier (newly appointed Executive Vice-President Products) was really refreshing and one of my TechEd highlights.
Here was an executive who started the meeting saying “why can’t we?” instead of “why should we?”. It felt very refreshing to be able to present our “openness and open source case” to someone who obviously understood the advantages of collaboration in the SAP ecosystem.
According to the feedback we received from this meeting,
“This meeting was a testimonial to the value the Mentors add to, and I want to thank you for your support. You were great!” the meeting was well received on the other side too.
Now I just hope SAP delivers.
One last note.
This is the comment from Tom Raftery, which was made on the night before TechEd had even started.
“SDN is supposed to be a community of developers. Why doesn’t it have a community-rated shared code library then? Or is that a naive question”.
Yes indeed, why not?
3 Responses to “SAP and Openness at TechEd in Berlin”
Leave a Reply
Additional comments powered by BackType
yojibee on January 13th, 2009
Sure, these are all small steps in the right direction.
What I miss most of all is a license, which allows several people to collaborate on community projects.
And when I talk about openness I am not only referring to the code, but also to NetWeaver as a platform. Unless you work for a partner, a customer or in one of the few countries with a subscription, you cannot access the platform as a developer.
What if NetWeaver was made as accessible as WebLogic?
And what if you would combine that with a code library and SVN?
Trond Stroemme on January 12th, 2009
Even old, stubborn giants can move… albeit slowly. We’ve had the SneakPreviews 8formerly known as miniSAP) since version 4.6C, something that at least shows SAP’s willingness to allow developers a hands-on system for their own training benefits. Of course, the problem is that you’re not licensed to actually create any finalized products for resale. The new subscription option seems to provide this possibility, although still geographically limited for some obscure reasons.
Secondly, with the advent of Saplink (also created mainly due to the vibrant SDN community) we now have the options of sharing and distributing code. Again, granted, not my (our your) employer’s code, which most employers have a legitimate intellectual right to under our contracts, but at least we have the tools and means for both developing and sharing “own” code, to an extent not seen until very recently within SAP.
As an example, there’s already the widget library; what about extending the SDN downloads section with a public library of (ABAP) contributions from the members? Granted, it would take some extensive house-keeping, since the mere dynamic of SDN and it’s contributors could rapidly drown it in a flood of contributions, but I’m sure it’s at least doable?
Looking at the amount of sample code already available (yet rather unstructured) in thousands of blogs and forum postings, I would imagine that such a library of relatively open-source SAP code, provided, tested and mutually enhanced by community members, could be just what many of us are looking for…?
Michael Koch on October 28th, 2008
Very interesting point Tom (and you) make in your last paragraph. However I think there is a twofold answer:
As far as SAP is concerned, there is a “code library” – the one that is accessible via SE80. Granted, it’s not community-rated and public (only to SAP customers), but there you go.
For customers and partners (the Z* and Y* stuff) the answer looks slightly different. Here the answer to Tom’s question is “competitive advantage”. Why should businesses share custom applications and developments on a large scale with a community? These are applications that improve their business and can potentially give them leadership in their market.
I am all for sharing knowledge to make future apps faster, more secure and speed up development process, but I don’t think a lot of my clients would like it if I shared (their) code with other developers on a public platform. At least not under the current regulations that are in place, like Non-Disclosure Agreements, for example. In my view, openness doesn’t work in ALL areas of enterprise apps. It has to be decided on a case-by-case basis.
But the good thing I took away from Berlin was that there is definitely something happening – and changing !
Kind regards,
M