This article follows up the How to present the licensed technology the right way? and explains the SDK design goals necessary to present the technology properly. As I promised in that post, it would be followed up by several short posts explaining various design goals, and this is the first one.
The first, and probably one of most important goals, is to design the SDK the way that it could be integrated quickly.
Why is it so important?
Imagine a company – a potential licensee – which tries to quickly decide whether to license the technology from you or from one of competitors. They got a copy of your SDK, and a copy of SDK from three your competitors. And a developer has one week to tell his boss which one works the best.
This gives only 10 hours per SDK, and during those ten hours the developer needs to:
- Ensure that the SDK indeed performs what the licensee needs, and that it does not have major issues when doing so (does not crash, uses too much resources, does not lock files etc);
- Ensure that the SDK works in the environment where it is supposed to work, and does not need resources which might be missing, such as GPU or Internet connection.
- Ensure that the SDK could be integrated by the existing team utilizing existing skills, and that the integration would be comfortable for the team, and would not be comparable to pulling teeth.
- Ensure that the SDK performs at expected levels on the area which is important for the company (i.e. it detects specific malware, could OCR a specific type of scanned document, or can compress video with required quality), while consuming the acceptable amount of resources.
Please understand and accept that the developer would need to get personal experience with all the matters above. Yes, you mentioned your technology is “the best”, and performs at the level they expect, that your SDK is easy to integrate and uses little resources. But so did every one of your competitors, so your technology doesn’t stand up here. More, if the company never worked with your technology before, they might wonder whether their definition of “the best” and “low resource usage” matches yours, and thus testing is still necessary.
To be able to perform the tasks listed above in time, your SDK shall allow quick integration. It still remains important even if you are offering free access to your technology, and thus not worried about competition. A product typically uses lots of technologies, built internally and licensed from external vendors (including open source components which are also licensed). It takes time and effort to learn the new SDK, and both time and effort are limited.
Thus our goal, as SDK designers, is to minimize the integration effort:
- Have the interface which is easy to understand and follow by looking at the interface description alone;
- Have the API which encapsulates the most common tasks such as (“scan this file for malware and return the result”, “scan this image and return the text”, “compress this video file and tell me when it is done”;
- Have the documentation which explains the typical workflow and is action-oriented (i.e. “to get this, do that”) instead of “here are 70 functions we offer, with detailed description of what each does, please read the following 140 pages of documentation and let us know if you have any questions”
- Have sample code which could be served as a base for the test app, and then copy-pasted into the partner application.