Category Archives: ByDesign

SAP ByDesign SDK – A River runs through it

Posted on by

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.

What’s good for SAP’s River isn’t necessarily good for BYD’s SDK

Yesterday’s Twitter post by Ethan Jewett struck me:

His last sentence was clearly aimed at the new C#-like language that SAP has introduced to allow third parties (so-called “solution partners”) to develop BYD extensions and add-ons. Whether or not this was a good idea is open to debate. In the end, only time will tell. However it is surprising to see that another cloud-based development platform by SAP has chosen a different route by allowing business logic to be developed in Javascript (which was one of my initial ideas in the BYD SDK post I mentioned earlier). So in contrast, SAP’s River development team leverages the vast amount of Javascript expertise on the planet.

No BYD Store (yet)

All add-ons for BYD are supposed to be delivered by an App Store like infrastructure, from where BYD customers can directly deploy the solution they’ve chosen for their core system. At TechEd in Berlin it was mentioned that the store would be up and running by end of 2010, but nothing has been announced as such yet. Back in October I was under the impression that a Q4 deadline was pretty ambitious for a BYD Store, so I’m not too surprised.

Community is good, Partners are better

At the TechEd 2010 Press Conference I asked the SAP panel whether or not a larger community was approached to help the BYD SDK to gain momentum. I thought the fact that BYD SDK is based on C# and uses MS Visual Studio as its development environment would be a perfect shoe-in for a large part of Microsoft’s C# community. Back then, the gist of the answer from SAP was that a more exclusive partner programme is the preferred way forward. Such a programme will also come with an entrance barrier attached to it, basically a monetary entrance ticket to the world of BYD add-on development. While such a partner price tag is not unheard of in the enterprise application space, it is clear that a higher fee will be hard to swallow for small, flexible software outlets and freelancers. Moreover, a move such as this would be even more surprising given the fact that SAP has been harping on about “Innovation” since SAPPHIRE NOW 2010. A final decision on entrance barriers for the solution partner programme has (officially) still not been made.

In addition, it appears that SAP is banking on consulting partners from the tried-and-tested On Premise world. A lot of noise was made at the recent SAP Influencer Summit about the fact that Accenture will become a BYD solution partner. Question here is whether this will really be the kind of inspired breakthrough in the consulting business that customers want to see (more agile approaches, shorter implementation, virtual consulting, less consulting overhead) or if it’s just a sign that the real aim is to deliver the same-old-same-old at equally high rates. A major point here will be the flexibility that bigger consulting players have got to offer. Or as a spectator in the SAP space commented in a conversation with me: “If you can’t play you can’t innovate”.

BYD UI question needs to be solved mid-term

SAP could also have problems on its hands with regards to the Silverlight UI that was chosen for BYD. Microsoft recently shifted Silverlight’s focus to the Windows Mobile world, which will have implications in the mid-term for SAP’s UI strategy for BYD. My take is that BYD’s external APIs could play a significant role for smaller consultancies that snub a potentially pricey partner programme and innovate “on the fringes” of BYD.

2011 Outlook

In 2011, SAP has to deliver a lot on its various promises (HANA, mobile, BYD, River, to mention a few). With a new conference concept (2 SAPPHIRE NOWs, May 2011 in Orlando, then November 2011 in Madrid for a combined SAPPHIRE / TechEd) the Walldorf concern certainly doesn’t shy away from the limelight. We are in for an exciting twelve months ahead.

Business ByDesign update and SDK

Posted on by

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.

Summary

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.

ByDesign? ByCommunity!

Posted on by

It’s been a while now since the fireworks of SAPPHIRE Now (my takes on day 1, day 2 and day 3). I thought it would be apt to have a little catch-up on what has said been about SaaS ERP in general and SAP’s Business ByDesign (BYD) in particular since then. I also want to add a few points re the SDK and beyond.

SAP has also produced a cute little video explaining BYD in a nutshell, which is worthwhile sharing.

Despite the simplicity that is presented here, ERP pundits have always been in agreement over the fact that anything SaaS based represents a new ball game for the old-skool “Big ERP” players such as SAP and their partners. In my view, the last few weeks have put a little bit more flesh on the argumentative bone.

Dennis Howlett provides some great insights and thoughts in his worthwhile read on “So you want to be a saas Consultant ?”. Dennis points the spotlight on the consulting and implementation partners for solutions such as Netsuite and ByDesign. Where is the possibility for them to make money? With regards to saas deals for small and medium sized clients he writes:

The upside is that in a deal of this kind, there is every incentive to ensure client success because you’re into a recurring revenue stream for as along as the client remains onboard.

This view is very much reflected in an excellent interview Jon Reed did with Skyytek’s Ray Tetlow (listen from 2:20 onwards). Skyytek has been working in the saas field as implementation partner for a number of years now and has 1000+ completed projects under its belt. Skyytek has also been chosen as BYD partner.

Furthermore, Tetlow points out that in his view classical ERP implementation firms will struggle to enter the saas market due to shorter implementation lifecycles, which renders long presales activities obsolete. It’s what Joshua Greenbaum calls a “tectonic shift in the marketplace”. Moreover, Greenbaum points out:

How SAP’s partners will make the healthy margins they need to be in the game with SAP has been, in retrospect, a bigger problem than the technology issues that stymied ByD’s initial release. And, by the way, thinking that value-added partners – the smart, savvy ones SAP wants to have on board selling ByD – will be happy with a volume business won’t cut it. Smart and savvy won’t be interested in volume, IMO.

Going back to Jon’s interview with Ray Tetlow this makes sense, as it appears that low office footprint, virtual consulting and less face time is what Skyytek’s model is shifting towards. Whether this will also be valid for larger saas projects and bigger end clients remains to be seen. Dennis points towards the importance of skills when implementations are done on a larger user scale:

Here’s the kicker – larger saas implementations require a lot more than understanding a general ledger. You really need industry expertise in order to help clients move towards implementing best practices and processes. I’ve argued many times that practitioners have these skills – they just don’t necessarily know it. Now is the time to think this through and think about how and where you’ll start assembling teams. The likelihood is you’ll need to look outside your own walls.

Greenbaum diverts the saas-interested audience to another topic which especially in SAP BYD Land is going to hot up even further over the coming months: BYD enhancements and tooling.

The good news for SAP is that ByD will have an xRM-like development environment by year’s end, one that can theoretically tap into a richer palate of processes via ByD than xRM can via Dynamics CRM.

Expect long queues when SAP’s BYD SDK “ByDesign Studio” (now renamed from “Copernicus)” will be available for 4 hour hands-on sessions at this year’s TechEd. What we know so far is that ByDesign Studio will be based on Microsoft’s Visual Studio, C# and potentially SQL Server. Despite some noises from the developer community I think this was a good choice, as SAP is able to tap into a pool of millions of developers who can innovate and extend BYD to their heart’s content in a “partner layer”. It can be expected that these ByDesign Studio based add-ons will use web services to access the ABAP-OO based BYD cloud system and leverage BYD’s Silverlight UI.

Skyytek’s Ray Tetlow believes that only larger custom developments like for example a call center extension are best use cases for partner solutions. Smaller extensions like custom fields or table enhancements can be customised by implementation teams and with little effort.

But where are solution partners going to market their extensions and add-ons in order to tap into the long tail? A go to market strategy for this still remains to be seen and answers will hopefully be provided during this year’s TechEd. Excitement for ByDesign Studio could be significantly hampered if SAP misses out to provide clarity on this when presenting ByDesign Studio. This is especially important with regards to pricing, if SAP is planning to take a cut in a “BYD App Store”.

Moreover, it will be important for SAP to mobilise beyond the existing developer and BPX community it has today, of which a large part has little or no C# skills. You might think that SAP ERP core skills are not that relevant anymore in this new field and you would probably be right. However, if ByDesign Studio really leverages web services then everyone who has used SAP web services before is in an advantageous position.

In the long run, it can be expected that these skills will become commoditised, but for the next 3-5 years SAP is going to have to engage not only with their existing community, but also reach out even further to those Microsoft developers it will eventually need. Given the uphill climb it already has on the partner involvement side, it is not going to get any easier.