Skip to Content

A few days ago, Rui Nogueira The role of Open Source in SAP’s Technology Strategy me on how open source supports the SAP technology strategy. A good reason to continue my blog. Which I am doing way too rarely. This time, I was almost on my way to title the blog post “Statistical errors or how Rui made me speak”. Yes, Rui made me speak. But why statistical errors? Because almost any time I used the terms statistic or statistical, I created a knot in my tongue … But watch yourself.

Radically simplified, our technology strategy can be stated as “Go mobile – go cloud – go in-memory”. At a first glance, this does not sound very compelling because all the industry is moving in these directions. That’s why we actually don’t look at technology for the technology’s sake, but for the sake to create new value from a business application perspective. How can our customers benefit from these technologies when applied to existing applications? Can they reach new users? Reduce their cost of IT operations? Decrease time-to-decision? And, perhaps more importantly, how can our customers benefit when applying the technologies to build new applications? Using Technology Strategy at SAP Part 1 and 2 words: “What types of applications can be built that could not have been built before?” How can consumer products companies connect to consumers using mobile devices? How can the airline industry optimize their flight schedules for the benefit of every airline using a joint on-demand solution? How can hospitals better react to demand changes initiated by external events using an in-memory application that crunches billions of patient records?

But what role does open source play here? An important one. And one that I also like to explain along a number of values. We have identified areas where open source software can systematically support our and our customers’ needs. Note that open source software is not better software just because it is open source. But in many cases, it does come with a number of benefits, depending on the use case. Here are four typical values:

First value: Reduce TCO

SAP supports SAP on Linux. This not only offers more choice for our customers, but also allows them to retain their Linux operation and administration skill sets in SAP environments such as SAP Business All-in-One. Many customers have migrated from a given UNIX distribution to Linux since Linux is a reliable and cost-effective operating system. Thus, the cost of migration paid off rather quickly. But Linux (and, thus, open source) also plays a key role in SAP’s on-demand offering as being the default operating system in the SAP cloud that runs SAP Business ByDesign. The same benefits apply – Linux’ reliability and cost-effectiveness allows SAP to offer Business ByDesign with an excellent service level agreement at a competitive price.

 

Second value: Reach More Users

If we want to reach more users, we can’t ignore open source technologies. And essentially, more and more the users (in the role of consumers or employees) decide which technologies to choose. Mozilla Firefox needed quite a number of years to reach a reasonable market share. Android was already much faster – note that the Open Handset Alliance was established by Google in November 2007, less than 3 ½ years ago. And, depending on the information source, Android is becoming or has already become the most adopted mobile operating system. As a consequence, if our customers and their users choose the client technologies they want to use, we need to make sure that these technologies can interoperate with SAP technologies so that a seamless interaction between mobile applications and SAP business applications becomes the norm.

 

Third value: Utilize Innovation Outside-In

The same holds true if we want to get an attractive content offering for these users. We simply can’t develop all mobile and Web applications, and, thus, need to work with and rely on partners as well as developer communities. Established and emerging scripting languages such as Python, PHP, Perl, and jQuery have large developer communities and we are much better off to allow them to innovate on top of the SAP platform. We do that, however, not by requiring them to learn SAP proprietary technologies but by allowing them to develop applications in the development environment they are familiar with. The trick is to establish connectivity to and interoperability with such environments through SAP Gateway, for example. The same will hold true for SAP HANA. While SAP and SAP partners are developing a number of HANA applications for various industries and application scenarios, we will at some point in time need to support the development of hundreds and thousands of such applications, including their adaptation to specific needs of individual customers. And the better we integrate HANA with existing third-party tooling like R, the statistical programming language and environment, the better we and our customers can utilize the many statistical algorithms the community of R developers has created and enhanced over time. Yet another approach on how to utilize innovation from the open source community in combination with SAP technologies.

Fourth value: Increase Development Productivity

The demand for increased development productivity was actually the key driver for SAP’s new approach towards open source software. While it is hard to estimate this in terms of saved person days, it simply does not make economic sense to develop SAP proprietary technologies if mature and well-adopted open source technologies exist. This is the main reason why the Next-Generation Java Platform consists of a vast number of open source technologies. In addition, the Java Platform team has evaluated a lot of open source development tools and methodologies that are needed for the distributed development approach often used for open source software. The Java development teams at SAP already make use of such tools and methodologies, which is another good example for how open source software helps streamline our own development process.

In both cases, there was often a need to fix bugs, add enhancements or integrate otherwise stand-alone technologies. Many or even most of such changes and enhancements are non-differentiating, that is, we don’t compete with the rest of the industry on these changes. And we don’t make money just with these changes. This is why it often makes economic sense to contribute them to the open source community and the projects that developed the original open source software. Not doing so would actually have a significant opportunity cost. Not only would we need to reapply the changes to every new version of the open source software. We would also risk that someone else would implement and contribute a similar feature that we eventually would need to comply with later by costly changing our proprietary implementation. Consequently, contributions to open source projects help standardize our investments and ensure continued innovation for the open source technology.

In some cases, it might even be reasonable to initiate new open source projects. The same logic of protecting our investments by standardizing our implementation applies, but it is certainly harder to ensure the success of the open source project since we first of all need to find committers and users from others, be them individual developers or other software companies. Fortunately, there are already a few cases where the product teams have been able to drive adoption through going open source. The often mentioned Eclipse Memory Analyzer was originally proprietary SAP technology. Going open source had the nice effect to create a level-playing field and convinced IBM to also support the technology on their own Java VM and hardware environments.

No value without commitment

One thing is clear: value does not emerge automatically. Or in other words, open source is not for free. Any open source technology we embed in our product line needs to comply with our product quality requirements. First commitment: if we distribute it to our customers, we are ultimately ressponsible to address any issue that might appear. Thus, we need to know the code simply to make sure that, for example, our security requirements are met and that we can ensure to support and maintain the software throughout our products’ overall maintenance schedule.

We do often apply bug fixes or enhance the open source software to add certain features or ensure its interoperability with other technologies. In these cases, there is a second commitment: we need to actively engage in the open source project. Not because of the license obligations, but to avoid that we create a fork from the standard. The fork would become more and more expensive to maintain. But the engagement with the open source community also has its price. Fortunately, over the last 2-3 years, we have gained quite some experience from working with the open source community in various areas.

And the third commitment comes from scenarios where open source technologies interoperate with SAP technologies: we need to ensure interoperability. Typically on our end. Taking Gateway as an example, if the invocation of a REST-based service provisioned through Gateway fails, we need to fix any issues that might occur between Gateway and the underlying SAP application. But we might also need to work with the open source community to, for example, build, adapt, and drive adoption for an OData SDK for jQuery so that jQuery developers can also develop apps that consume SAP through Gateway.

Economics 101: as long as the benefits outweigh the cost, we can utilize open source technologies. And we do that in a way that they support our technology strategy.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Markus Doehr
    …Linux as our main OS to run services, not only for SAP software and big databases but also for other non-SAP applications – where possible.

    Some time ago we started a project to evaluate whether it’d be possible to create a desktop completely based on open source software but we failed eventually because SAP does (still) not support OSS in the same way as proprietary (speak: Microsoft) software.

    Starting with browsers (e. g. Firefox) not supporting portal administration functions going over XXL-/ALV-Grid-Exports to StarOffice/OpenOffice/LibreOffice and ending in SAPGUI for Java not being able to display certain transactions (e. g. in SolMan) properly – amongst other some-dozen small issues.

    SAP is IMHO (unfortunately) still focusing too much on Microsoft when it comes to frontends and UI, what I can understand to some extent (Business!). It’s just unfortunate because eventually it makes OSS on the desktop an unreachable goal.

    On the server side it became good, Linux is very well supported on most applications and databases. I believe that the recent announcement of Oracle not more delivering their next software on IA64 will bring even more customers to Linux.

    It would be great if Firefox can at some point completely replace IE and its rendering engine so customers will be eventually able to ban that piece of software from the desktop (for whatever reason).

    Just my EUR 0.02


    Markus

    (0) 
    1. Claus von Riegen Post author
      Thanks, Markus.

      Valid feedback – there are certainly limitations when it comes to the usage of open source software on the desktop. The Platform Availability Matrix on the SAP Service Marketplace tells you which SAP solutions might have, for example, limitations when it comes to the usage of Mozilla Firefox. It this limits the usage of SAP solutions in your very context, I would recommend that you a) find others on SCN with similar requirements and/or b) work with your SAP user group to consolidate these requirements so that we can find the right channel into our product teams. What I would really like to see happen is a much more straight-forward support of any browser technology through the use of standards such as HTML5.

      As for ODF (and, thus, OpenOffice.org/LibreOffice), this is actually supported for the SAP List Viewer. Please see Erwin Tenhumberg’s blog (I believe from 2008) on the topic.

      What do you think about opening a dedicated forum or wiki on the topic of open source on the desktop?

      Claus

      (0) 
      1. Markus Doehr
        Hi Claus,

        thank you for commenting.

        The “browser support” has been and still is a big thing when working with SAP software. Often it’s just impossible to update the current stack to the newest level that supports current browser versions. You can see that very nicely currently with IE9 where you have to make sure the IT sets the proper switches in registries and settings to make people continue to work with the software; and even then – if you check e. g. CRM 7 it’s still not 100 % working.

        Especially the browser seems to be “let’s make it work on IE and then check what other browser can be made supported” – and not “it must be working on all”. I follow(ed) that discussion on various DSAG groups for years (since EP 5.0) and I have to admit that I ‘gave up’.

        Maybe the hype for mobile applications will bring (new) customer requirements to the right place, maybe.

        Another popular example is Solution Manager, a “technology platform” which does simply not work 100 % on non-Windows GUIs, neither the sapgui version nor the web version/web gui. I consider this pretty antagonistic when technology = Microsoft-IE-only. Not an allegation, just an opinion – or just a marketing vs. technical person misunderstanding 🙂

        I guess it wil not be possible to bring the *current* software stacks to a state, when they can be used with non-MS operating systems or non-IE, not even mid-term. And until not all of the used packages are enabled, customers will still have to deal with restriction. It doesn’t help if just an EHP2-Portal will work with Firefox, all other software needs to work too until one can switch.


        Markus

        (0) 
        1. Claus von Riegen Post author
          Hi Markus,

          thanks for your honest feedback. And you are probably right in that we won’t be able to support all types of Web browsers for all of our existing products. But we can learn from that and promote a more open, standards-based browser support in the future (around HTML5, JavaScript, etc.).

          Claus

          (0) 
          1. Markus Doehr

            …and just to add more, I just couldn’t believe it:So maybe the SCN/SDN should be put on Sharepoint, the forums are faster and it even supports drag-and-drop in Firefox when uploading stuff and I can even using word as editor for blogs.Markus

            (0) 
            1. Claus von Riegen Post author
              I can’t believe that either. This qualifies for a CSS message and needs to be fixed. We can’t require SCN members not to use Firefox.

              Claus

              (0) 

Leave a Reply