SAP Mentor Daniel Graversen's blog How to be a small sap software vendor provides tremendous insight into the difficulties that independent developers and contractor experience in proliferating their best work.
The cost of test systems combined with the cost of certification factor into making it almost impossible for the independent to share code on a commercial basis.
Mrinal Wadhwa, another Mentor, puts forward the idea that:
But, lets consider the example you gave, a small add on, lets say hypothetically it costs one developer $20,000 worth of time to build this add on, now lets say there are 200 teams around the world that need this addon (generally there are more), now since they can't buy it from anywhere they all develop it independently, total cost to SAP customers $20000x200 = $4million .. instead if these 200 teams could've just bought this addon from the developer for say $140 ... total costs to SAP customer $28000, that is 0.007 of what it would've costed the customers otherwise. The independent developer who made the addon earns a 40% premium on his hourly rate, that makes is so much better for him than consulting work. The teams who bought the addon get to focus on solving more complex problems rather than focusing on the this redundant add on. SAP gets happy customers. Everybody wins !
Not quite. In Mrinal's world, SAP doesn't see a dime - at least not directly. I'll get there in a minute. Mrinal then goes on to talk about the quality issue.
But, what about quality ? .. well actually its way better than the one off implementation that the consulting team would've made, because the same addon gets used over and over again its quality improves because of all the feedback it receives from repeated use by new customers, and these new improvements can also be sent to old customers. This process of natural selection and improvement actually ensures that only the highest quality code gets used in production. I think this process will work way better than any certification process ... we all know that that its impossible to reliably vet the quality of code without trying it out in a real environment for some time.
I can see that going down like a lead balloon in the hallowed halls of Walldorf. That despite SAP management is aware this is an issue.
As an accountant by trade and VERY occasional code jock (I don't count myself among the rock star geeks) I think I have a solution.
At Mrinal's pricing, any dev shop will pony up $140. I'd bet they'd spend $250-300 without batting an eye, especially seeing as that fades into insignificance when set against $20K for their development and that's before they add a markup. So let's work with both $140 and $250 and Mrinal's 200 dev shop estimate. You'll see why in a few minutes.
Whether Mrinal is right about real world testing as opposed to SAP QA is moot for the purposes of this argument but let's assume SAP feels the need to test because of legal issues. That's a real threat so let's not kid ourselves here. SAP puts the minimum price on that sssurance at $7K. But as an upfront cost it represents a genuine barrier.
SAP loves to talk about co-development so why not add that into the mix? See where I'm going?
Here is the business case:
Using my numbers, our little add on could generate $50K via the hub. Our developer could take his $28K leaving $22K or 44% for SAP. That more than covers the test cost AND drives revenue for the Ecohub. Now everyone is really happy because in my scenario, the downstream improvements that Mrinal envisages continue. SAP has enough money from the deal to apply incremental tests so our add-on is not only more useful but it carries SAP's assurance.
Why will this work? Mrinal makes the initial case but I will go seven steps further.
- The precedent for this has largely been set through DemoJam. Here are my reasons for making this assertion.
- DemoJam ringmaster Craig Cmehil likes to bring past winners on deck to demonstrate the value of what they showed in the previous year. As I recall a year or so back, he said that one company increased business 500% as result of winning DemoJam. Was it a tested solution? I've no idea and it doesn't matter because no-one is going to turn their noses up at that potential. And all from two geeks getting in front of maybe 5-7K developers. If solutions are in the Ecohub then they will have the potential to reach millions and in those circumstances 500% will likely look shabby.
- DemoJam represents a microcosm of the small dev shop. When our group developed ESME, there were half a dozen or so folk on the team, cranking code and designs in spare time for less than 12 weeks. More often than not I hear about tiny teams doing much the same thing. I'd bet a lot of money that if ESME could have made it to Ecohub it would have proved wildly popular. But that's another story. My point is that small teams can do great things. Here's an example.
- Anyone remember Ed Herrmann and Dan McWeeney's SAPLink? It won DemoJam back in the day. The current download number for the Web_DynPro-0.1.0a.nugg file is 8,450. The data dictionary has been downloaded 10,806 times. It still has committers. It's open source but could have been a paid for item. $50 anyone? The best stuff always generates demand.
- Co-development means shared risk. SAP does this with customers so why not with independent dev shops? As I have demonstrated, even with Mrinal's de minimus estimate of demand and my calculations of revenue, everyone including customers is a winner.
- SAP doesn't have a choice. In offering Business ByDesign at a ticket price of $149/user/month with a minimum user count of 10 it is signaling the lower end of revenue expectations at $17,880 pa. Expecting developers to pony for test systems and testing at current levels is unsustainable. SAP will have to develop a far more attractive model for this line of business. That would have to go the same direction as Mrinal is suggesting to come close to the BYD model. SAP knows it has to test BYD add-ons to ensure they don't break the multi-tenancy upon which BYD relies but that cannot be done at prohibitive cost and especially when SAP will (not might) rely on armies of small devlopers to fill in white spaces. If SAP goes this route then where does that leave add-on development for other solutions? They have to fall into line otherwise there is no logic in doing ANY development for Ecohub purposes other than out of the goodness of people's hearts. Last time I checked, that didn't pay the rent.
- Daniel and Mrinal's argument about repeat development resonates very well. For too long, SAP customers have effectively overpaid for code that doesn't always stand up. This method solves that problem at a stroke.
Large dev shops will go nuts. It is a disruptive model for them when they can charge over and over for the same stuff but that's too bad. The world is changing and the model I am outlining above is the way of the future. If you don't believe me then ask yourself this: why did Salesforce.com acquire the Heroku community? SAP doesn't have to do that. It already has a massive vibrant community of dedicated and seasoned developers.
SAP is moving many solutions towards 90 day development cycles. This model fits very well with that idea. It adds an urgency and drives focus towards delivery. It matches what we see in DemoJam development timelines. This model is therefore an accurate reflection of what is already happening and what is needed across the whole ecosystem.
Finally...I'll make an emotional plea. SAP Mentors are among the best in the SAP ecosystem, according to SAP. Most represent small dev shops or are independents. A few come from large shops like IBM. Some are SAP employees. Imagine what an incentive it would be if Mentor code ended up on the Ecohub? Imagine how many other coding stars might emerge as a result? As it stands today, that isn't going to happen. Is that what SAP wants for its best? I cannot believe that.
But what do you think? Have I done enough to create a convincing business case or could it be enhanced?
