This is a seventh article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
We already discussed in the previous article, SDK Design Goal #5: Design for Extra Functionality, that when you initially develop your technology to be used internally, usually only the API necessary for the internal use is exposed. Thus you know extra work is needed when the technology is prepared for licensing, and now you are trying to decide which functionality should be available from your SDK.
Here you got a dilemma:
- You can export all possible functionality, and even add up the missing functionality which you think might be useful. This makes your SDK suitable for the customers who have unique requirements, and are not afraid to spend significantly more effort to integrate it. However the majority of your customers would not need all this functionality, and some of them would be turned off by the perceived difficulty of integration. This goes against our quick integration design goal.
- You can only export the necessary functionality which most licensees would use, and decide not to offer more advanced functionality. Now your SDK looks simple, covers the needs of 80% of your customers, and could be integrated quickly. Unfortunately you might soon find out that the remaining 20% customers who require those advanced scenarios are large companies, who already developed existing solutions and see no reason to change their working code to account for inefficiency of your technology. Being large companies, the revenue they could provide to you might match the revenue from your 80% user base, but you’re losing it because your SDK is is not designed for functionality.
So how do we solve this dilemma, if making the SDK more complex hurts integration, and making it less complex hurts functionality?
The solution is easy: in this case you need to provide two (or even more) different SDKs. Those SDKs may use the same code base internally, and provide access to the same features, but through different APIs. One set of API could offer quick integration scenarios which 80% of your customers would be satisfied with. Another set of APIs could offer rich functionality, but would be considerably more complex to integrate.
When doing this, the following advice might be useful:
- When you develop using this approach, it makes sense to develop the most complex SDK first, and base the second, quick-integration SDK, using the other SDK as a base. This way you can maintain the same underlying code base, and ensure proper engineering, QA and support cycles.
- By having several SDKs offering the same technology with different APIs, you can reach a larger audience. However it requires more knowledge from your sales team, notably sales engineers, because the consequence of offering a wrong SDK – such as offering a fully featured SDK to a customer who needs quick integration – would waste all the effort you put into separating the technologies.
- This approach can also accommodate the difference between platforms. For example, if your SDK offers direct integration into e-mail gateways, this integration would be significantly different on Windows (Exchange) and Linux (Postfix, CGP, Exim, etc). Here the original SDK, exposing all underlying mechanisms, doesn’t even have to be exposed, and you can just offer several different SDKs for each platform/component.
A final note: spend some time explaining this approach to your engineering team. Some engineers might consider this approach as duplicating their effort (“how, they really can’t dump the memory buffer into the file, pass it to our SDK, and then delete it? that’s like 10 lines of code!”), and it is in your best interest to help them to understand what it is not duplicated effort, but valuable work which is highly beneficial for the company, and results in much better technology adoption, meaning more people would be using the technology, meaning better exposure and larger revenues. And this is what engineering is usually happy about.