Business ByDesign update and SDK

This year’s SAP TechEd enabled developers for the first time to test-drive the toolset to create Business ByDesign (BYD) extensions. These so-called “add-ons” can enhance SAP’s mid market cloud ERP system. Day 1 of TechEd gave me the opportunity to talk to Rainer Zinow, SAP’s SVP for ByDesign during a Q&A session. Next day I got my hands dirty in the SDK hands-on session. Finally on Thursday I helped SAP with some Usability testing for the SDK. In other words there were lots of opportunities to gather first hands experience!

Focus on Partner Ecosystem

SAP is still in the process of establishing and educating its BYD partner network. As far as BYD add-ons are concerned, it can be expected that this selective group will be SAP’s prime focus for training with the Software Development Kit (SDK). A post-keynote press conference revealed that currently SAP is not planning to reach out to other external communities to increase uptake in developers. Whether this is a good move remains to be seen. More on this further below when I touch on the tooling and scripting languages.

No information was available with regards to partner add-on pricing. My own interpretation is that there are two options for SAP: either charge a high entrance fee to become a BYD add-on partner and thereby raising exclusivity and limiting development community exposure; or keeping the entrance barrier low and attracting a larger community to spur on innovation in this space. Should the Walldorf company opt for the high price route it’s likely that BYD add-on partners aim to recoup the high initial expense with higher prices for their developed extensions. This would obviously be counter productive, especially when keeping in mind that SAP is going to present an app store-like storefront for the BYD add-ons later this year. My take: Leaving out the community focus here can make or break the quality of the add-ons offered.

Client copy and APIs

It was good to learn that SAP will enable the copying of data snapshots from productive clients to development, test or sandbox environments. These copies have to be requested by the customer (not the partner) and will be executed by SAP. It is envisaged that this could become an automated process in the future. There will also be 2 different APIs for BYD, one internal (so called A2A, enabling SAP pr partner BYD functionality to talk to each other) and A2X (= external), allowing other platforms to interact with BYD cloud apps.

New scripting languages, BODL and ABAPScript

SAP seems to have settled on “ByDesign Studio” as the final name for the add-on SDKs”. Hands-on sessions still showed a “Copernicus” icon on the desktop, which was its previous code name. BYD Studio is based on Microsoft’s Visual Studio, which was a conscious decision by the Walldorf software engineers as their analysis revealed that about 60% of mid market partners are already familiar with this development environment for .Net and C#.

On the language side, it was previously mentioned that C# would be the basis for BYD SDK, but SAP decided to choose a different route in this respect. Logic for BYD add-ons is written in two scripting languages called Business Object Description Language (BODL) and Advanced Business Script (I’ve also seen it called ABAPScript during the hands-on workshop). This obviously throws up a few questions.

Why two scripting languages and why not use C# ?

First of all, BODL is used to define any additional Business Objects for BYD add-ons. Obviously SAP made a conscious decision here to not integrate it into the BO layer in the BYD cloud backend, but instead define using BODL code in BYD Studio. According to SAP, C# would not have been flexible enough for BO definitions, thus the creation of BODL. See an example of some BODL script below:

On the business logic side for add-ons BYD Studio uses a reduced scripting set which is based on C#. These scripts are deployed onto the BYD SaaS system and then generated into ABAP statements. Yes, you have read correctly, ABAP code is created from the scripts you define in BYD Studio! When asking about the reasoning for this I basically received two answers.

Firstly, SAP expects more partners to be conversant with a C#-based scripting language, as this is what the current tooling for a lot of partners is. This was also the reason why it was chosen over ABAP, which could have been the obvious development weapon of choicechoice.

Secondly, the cloud-based nature of BYD forced SAP to build a protected and walled garden around any code changes that are made. A reduced instruction set which then generates ABAP code in the cloud was seen as the safest choice here.

Impact on skills

These surprise developments bring up a few questions around skills for me. What is the potential skills mix for a BYD add-on developer? My take is that experienced C# developers might shy away from a reduced version of the language. However they have the advantage of knowing the tooling from the bat and can tuck right in. ABAP developers might have a slim advantage in terms of creating performant code as they understand the generated code base better (even though they can never see it). In conclusion, I would say that none of the groups have a distinct advantage, which is slightly disappointing.

All in all I have to admit that the concept of a generated ABAP code base is understandable due to stability considerations. However, I think that SAP misses a trick here by offering 2 new scripting languages that do not really fit into any camp. Maybe a Javascript-based framework would have been better, as it is wider adopted and known. I am convinced though that we have not seen the end of the line here yet. SAP is slowly feeling its way into the unknown caverns of SaaS and cloud land. I am sure we will see smarter solutions here in the future.

Overall impressions, stability and skins…

Generally my observations were that BYD Studio worked reasonably well. BYD Studio is part of feature pack (FP) 2.6. Since this release is still under development the hands-on students had to cope with a few hiccups such as login popups to renew sessions, but in conclusion the SDK worked well and seemed stable. At the end of the hands-on workshop questions were asked around numbering ranges and localizations and the answer was that features such as this are not available for add-ons yet, but are being looked at.

One disappointment was the skin that was used to display BYD screens during TechEd. SAP chose a tradeshow-like design in Silverlight that basically gave BYD a very SAP-like look and feel. In my view this is a wasted opportunity to create something new and fresh. I remember that during SAPPHIRE a different, fresher skin was used to show off the product. Why such a boring skin was chosen is hard to understand, especially if one keeps in mind that Silverlight is used as the UI weapon of choice here.


In summary my first impression of the SDK was slightly positive. The product seemed stable and ready. The choice of scripting languages (BODL and a reduced C# dialect) seems odd and might turn out to be a bad call in terms of community engagement – a key ingredient when trying to create an online app store like experience for BYD. Main reasoning here seems to be cloud app security and that’s fine. However, I’m convinced SAP will pull something smarter out of its hat in the future. Whether it will hem add-on developer uptake remains to be seen. I also heard that SAP in the future plans to offer trial-like versions of BYD SDK for non-partners, which would be an important and welcoming move. Let’s watch this space.

SAP has got to decide if and how to engage with a larger community. I hope it chooses a route where developers are involved and entry barriers are low, so the BYD app store can show a larger number of innovative add-ons at a reasonable price.

I’m looking forward to the presentation of a BYD app store later this year and can’t wait to see the first add-ons doing some BYD magic.

14 thoughts on “Business ByDesign update and SDK

  1. Fred Verheul

    October 15, 2010 at 7:07pm

    Hi Michael,

    I was there as well (i.e. in the hands-on session), and heard from a fellow-attendee that (to his experience) SMB’s with in-house IT could learn this scripting language(s) in a couple of weeks. So the need for partners developing add-ons remains to be seen. The opportunity might not be as big as partners would like it to be. This in contrast to the big enterprise world where the need for (specialized) partners is clearly established.

    Just a complimentary thought…

    Cheers, Fred

  2. Michael

    October 15, 2010 at 7:26pm

    Hi Fred,

    Excellent point you are raising. Yes, I agree that the scripting language should be easy to learn. Upcoming documentation will reveal more here, but there shouldn’t be too much of a learning curve. But like with ABAP (which has a bigger learning curve, agreed) the REAL art lies in knowing the business objects and functionality. This might be the decisive area!

    Also, some SMBs I’ve worked for (around 200 employees) has a multi-skilled IT team where 1 team member looks after several areas (SAP, Notes, network admin). I can’t see smaller companies getting their hands dirty themselves. Maybe for a little fast ordering screen (like the one we created in the workshop), but not a larger solution like travel expenses or a wine yard add-on. These solutions would be provided by externals (I’m not saying “partners” here on purpose!).

    Kind regards,

  3. Michael Koch

    October 16, 2010 at 1:58pm

    Hi Holger,

    Thanks for the link. Yes, I’m already in contact with Damian. 🙂


  4. SAP TechEd: the wrap | ZDNet

    October 22, 2010 at 3:50pm

    […] a hands on developer session designed to demonstrate BYD’s customisation capabilities. Michael Koch provides the SAP developer perspective from his attendance at the TechEd Berlin event. My take is that SAP developers with a knowledge of […]

  5. Faycal Chraibi

    October 25, 2010 at 10:21am

    Hi Michael,

    Nice overview there. I was interested in the hands-on and usability tests, unfortunately, it conflicted with other sessions.

    This looks promising. Although from an SAP perspective, it might be surprising to opt for a derivative of C#, my previous experience has shown that this is the preferred language for SMEs. There is a widespread range of skillset that should allow them to build and maintain their apps.

    Now, it would be interesting to see how this works:

    – Entrance model for the partners.
    – What about customers ? Will they be allowed in ?
    – Sales channel for the apps : Will there be a store where customers could find potentially interesting apps for them ?
    – Ability to integrate ByD with other cloud services by leveraging APIs ?
    – Will there be an API for Business By Design ?

    After a few ups and downs, ByD seems to be on a pretty good shape and I have the feeling that there will be some interesting developments to come in the near future.

  6. Michael Koch

    October 25, 2010 at 9:13pm

    Hi Faycal,

    Re customers and allowing them in: Given the size of BYD potentials, I guess only a small minority will be interested in developing their own add-ons. But never say never. Especially if BYD is a platform for larger implementations (and larger customers), then this aspect will get more focus.

    Re Store: Yes, there will be an App-Store like online shop. We were informed at TechEd Berlin that something will be presented later this year.

    re APIs: I already wrote about the A2A (BYD to BYD) and A2X (BYD to external systems) APIs. More information re these will come out over the next weeks and months, but it’s good to know that these will be put in place. The A2A API offering will be larger than it’s A2X sibling, but that was to be expected.

  7. Martin English

    October 25, 2010 at 10:46pm

    I was in the same hands-on, at the back (i came in a little late). A couple of things that I found frustrating with the SDK were:
    * no simple way to ‘internationalise’ the screens. Depending on where an SMB is located, this matters; Every SMB in Australia is, or wants to be, an exporter. For example, an acquaintance of mine runs a $AUD15M turnover business, that imports from Europe to Australia, designs, assembles then exports to South East Asia. Even across Europe, I would have thought this would be a necessity,
    * The development tool itself was clunky; Am example was changing the text value in a header field – When something is called ‘xyz Studio’, regardless of the vendor, I expect to be able to change a property by typing over the value in the properties list (much like Visual Basic).
    * I had some other issues, like having to login repeatedly to one of the tools we used, but I think this was an issues with the network connectivity as much as anything.

    I know the SDK is meant for partners, not end customers, but I can see it being ‘slipped’ to the customer by a Partner or two, as a favour. In that situation, where the ‘IT’ department in an SMB is usually one or two people plus some outside contractors, consistency between tools is very important. Even within a Partner, consistency between tools can only help productivity.

    Having said all that, the SDK is still in Development and even when released, it will still only be version 1.0 of the SDK (although SAP would be silly not to keep the numbering in line with the ByD sequence). From a Partner developers point of view, its a wonderful improvement on what they have now (essentially nothing).

  8. […] to understand with almost none of ABAP’s arcane language peculiarities to contend with. (Check this code snippet from Michael Koch’s more technical assessment.) Since this is SAP, they didn’t go find a scripting language and modify it for BYD. They […]

  9. Faycal Chraibi

    October 27, 2010 at 2:44pm

    @Michael Koch

    Hi Michael,

    Actually, the idea behind the customer ticket-in BYD developement is an opportunity for some customers to have some small sites, countries, affiliates where they cannot afford to spend a huge implementation project to use BYD.

    So the customer might be a big SAP customer but with a small affiliate in some country. In that case, they’d be able to develop a specific app to handle some processes.

    Up to now, many customers have done this using SAP Business One. In the future, there might be a shift from Business One to Business By Design.



  10. […] As 2010 is drawing to a close it’s probably a good point in time to take stock on SAP’s Business ByDesign SDK. For those who are not privy to the topic: SAP’s cloud-based ERP offering for the small and medium sized enterprise called “Business ByDesign” (BYD) is extendable by a software development kit (SDK). Said SDK was introduced at 2010 SAP TechEd conference and participants were able to gain some hands-on experience with an early release of the toolkit. More insights and a thorough review of the SDK can be found here. […]

  11. Judson Wickham

    January 21, 2011 at 10:22pm

    I am a BYD customer and I’ve requested access to the SDK a great number of times. I’m really hoping that SAP will open this up to a larger community.

  12. Michael

    January 21, 2011 at 10:52pm

    Hi Judson,

    Thanks for your message. I’m not sure as to what the arrangement is with SDK access for customers, but I’d guess that you have to go through your BYD partner. Things will get clearer once more solution partners are on the scene (the ones who who will be involved into custom developments and add-ons).

    Kind regards,

Comments are closed.