Skip to Content
Some SDNers may say that we as a community have no obligation to help SAP “sell” NW/Enterprise SOA to existing and prospective members of the SAP community. This point of view is so obviously wrong that I won’t bother to refute it up-front. But if you really do think that we DON’T have this obligation, tell me why in detail and I’ll tell you why you’re wrong in detail. OK – so we’re all agreed that SDNers have an obligation to help SAP “sell” its vision. One way to do this is for SDNers to try and convince existing SAP customers that NW/Enterprise SOA is so “ready-for-prime-time” that it can even compete as pure technology against any other software development package. This is a very different approach than the one currently being followed by SAP – to try and “hitch” the NW/Enterprise SOA “wagon” to the “star” of business process re-engineering. When SAP pitches NW/Enterprise SOA as the underpinning of business process re-engineering, SAP is telling customers to do yet again what they already did when they went to ERP in the first place: rework their business processes in functional areas that SAP covers. And therefore, SAP has to overcome the skepticism of customers who have at this point gotten a little suspicious of each new latest-and-greatest paradigm being pitched by the US$300.00/hr folks. In the approach I’m suggesting, the pitch would be that NW/Enterprise SOA can not only be used in all the good ways that the Enterprise SOA gurus suggest, but can also be used throughout a company as a pure technology package for doing things the company has always wanted to do, but didn’t have the means to do. If you’re an SDNer working for an existing SAP customer and have any “clout”, you are certainly in a position to pitch SAP NW/Enterprise SOA as a pure technology solution to ANY IT problem in your company or organization, not just ones in domains that SAP covers. But what if you’re an SDNer working for a 3rd party firm: consulting, integrator, or implementor? Well, if your firm has at least one “in” with an existing SAP customer “C”, what you can do is to convince your firm to do the following: 1. Buy the HP/SAP NW combo package – it’s almost “free” considering what you get. (Of course, SAP might have to remove the requirement for buyers to have an ERP license.) 2. Pay for some training (maybe SAP would even discount a little here?) 3. When the SAP customer “C” comes out with an IT RFP in an area not covered by SAP, bid a solution that relies on NW/Enterprise SOA as pure technology. 4. Tell “C” that NW/Enterprise SOA is so “easy”, you’ll even do a “loss-leader” prototype to show “C” how quickly and easily you can deliver the needed solution. What’s in it for you? The best pay-off of all: continuing opportunities to do interesting work with intelligently designed software.

To report this post you need to login first.

10 Comments

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

  1. David Halitsky
    Item #1 in the above post should read:

    1. Buy the HP/SAP NW combo package – it’s almost “free” considering what you get. (Of course, SAP might have to remove the requirement for buyers to have an ERP license.)

    (0) 
    1. John Patterson
      Hi David,
      From what i reading the same license restrictions apply for the discovery systems as with any other system.

      Re: Licensing requirements for Discovery System

      This means that you may not be able to develop or apply patches etc.

      For a cheap alternative for training, try the  Online Knowledge Products OKP’s
      http://service.sap.com/okp
      They are a lot cheaper than classes and are self paced. I have found a couple of them to be a really good introduction and on going reference.

      Cheers
      JSP

      (0) 
      1. David Halitsky
        at TechEd 2006 LV, I suggested that in return for removing the licensing restrictions that prohibit folks from buying the DS purely as a technology platform, SAP could have; i) right-of-first refusal on any new application software developed on a DS in a sector not already penetrated by SAP; ii) the usual 93% lion’s share of any revenue stream resulting from such software development.

        So SAP would, in effect, be getting some very cheap R&D at a fraction of the 75% of revenue that SoftwareAG supposedly sank into its products yearly.

        (0) 
        1. John Patterson
          Hi David,
          Having read the terms and conditions of being a certified XApp partner, I think they may have already thought of some of your ideas a while ago.

          Cheers
          JSP

          (0) 
          1. David Halitsky
            … so thanks for pointing it out. 

            But doesn’t the idea of developing an “XAPP” imply developing something that bridges existing app’s, and thereby something built on top of pieces of already licensed “ERP” software (or CRM or what-have-you)?

            I was thinking of NW/ES(O)A as pure technology for development in areas in which SAP presently offers nothing at all.

            But I take your point about the “XAPP” partnership schema also applying to development independent of any current SAP content area.  It’s really up to how forward-looking Walldorf wants to be right now.

            There was some discussion here a while back about whether SAP should/could become a pure technology company as opposed to an app provider.  I argued in that thread that it is by no means an either-or proposition.

            Thanks again for the tip on “XAPP Partnership”.

            Regards
            djh

            (0) 
            1. John Patterson
              Hi David,
              I am not too sure about the finer points. After reading the prerequisites of becoming an Xapp partner what i can tell you is
              – you need a good business case
              – a scalable prototype
              – income to sustain a defined period of support and development
              – available resources for knowledge transfer with SAP
              – a marketing plan
              – some sites which have agreed to pilot the applications

              As far as what defines an Xapp, initially I read it as an existing application, or new application which could be ported or developed into a solution which used 2 or more of the following technical enabling components EP, PI or BW.

              That was before I saw the Xapp XMii. SAP identified a gap in their arsenal when it came to ‘Adaptive Manufacturing’, so they acquired an MES related product called Lighthammer.

              XMii appears to be it own self contained framework/business suite, sure it is possible to integrate to all of the enabling technologies, from what i hear it is also sold to non SAP sites as a stand alone product.

              Therefore can the definition of Xapp be seen as ‘any development in areas in which SAP presently offer nothing at all’ – include your own dotted lines for integration to the enabling technologies.

              Cheers
              JSP

              (0) 
              1. David Halitsky
                is fine if there are enough folks out there ready for Stage 1.

                If there aren’t, then it might be worth SAP’s while to promulgate a Stage 0 set of rules for those who can’t get pilot volunteers until they have a prototype up and running.

                Again – I go back to the analogy I’ve used before here … UNIX and its descendants beat out MVS and its descendants because several generations of highschool and college students grew up playing with it for free at their schools.

                Thanks again for the further info – I’m sure it’s useful to others here as well.

                Regards
                djh

                (0) 
          2. David Halitsky
            … so thanks for pointing it out. 

            But doesn’t the idea of developing an “XAPP” imply developing something that bridges existing app’s, and thereby something built on top of pieces of already licensed “ERP” software (or CRM or what-have-you)?

            I was thinking of NW/ES(O)A as pure technology for development in areas in which SAP presently offers nothing at all.

            But I take your point about the “XAPP” partnership schema also applying to development independent of any current SAP content area.  It’s really up to how forward-looking Walldorf wants to be right now.

            There was some discussion here a while back about whether SAP should/could become a pure technology company as opposed to an app provider.  I argued in that thread that it is by no means an either-or proposition.

            Thanks again for the tip on “XAPP Partnership”.

            Regards
            djh

            (0) 
        2. Amir Blich
          Hi David,

          I’m not sure that SAP having a straight forward ROFR (Right Of First Refusal) would be positively received by our ecosystem members. Even though we still have similar licensing terms in some areas, they are mainly meant to protect against core modifications in the ABAP area that might impact other customers.
          I see a ROFR as an adoption inhibitor which we should limit as much as possible.
          As we announced in Amsterdam (unfortunately I was unable to discuss it with you some weeks earlier when we met in LV), the SDN Subscriptions program is planned to make it easier and more cost effective to access developer licenses and tools for the NetWeaver platform and we are doing so to encourage new innovations around our platform which will be quite difficult if we always had the ROFR. I’ll share more information about this program in the beginning of 2007.

          Regards,
          Amir.

          (0) 
          1. David Halitsky
            It’s probably true that if you don’t require an ROFR clause, you will attract the hungrier entrepeneurs, and therefore those who are more likely to actually develop products which redound to the benefit of SAP, albeit indirectly.

            And of course, if a product is really good, SAP can just make its maker an offer it can’t refuse.

            (0) 

Leave a Reply