This is a third article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
So if you followed the Design Goal #1 article, your design is good and you assume you got everything needed for quick integration. Your SDK provides all the functionality you think the customers might ever need, it has every options you think the customer needs, and retrieves all the data you think the customers might ever need.
This is true, and will stay true until you get your first real customer, who’d be using your technology. And what happens next?
Apparently your customers need more features! Pretty soon you find they want more detailed options, and want more information about the object, including the one you considered useless. For example, a customer might want to encode only a part of the image. Or scan for malware a file stored in a non-continuous memory buffer. Or perform OCR on a specific frames of a video file.
Sure, many of those requests could be worked around by the customer itself. This means a customer would have to write extra code, sometime complex, in order to address what they see as deficiencies in your technology. Since our goal is to design for quick integration, this is something we would certainly like to avoid.
Note that besides extra effort, there may be some other consequences, such as:
- If a customer wants to pass the data stored in a non-continuous memory buffer, you can ask them to create a continuous memory buffer and copy the file there/save it to disk and then pass it to your SDK. However this is not a good solution, because it would result in increased memory/disk usage, so a competitive SDK implementing this functionality internally would be a much better choice.
- If a customer wants to perform OCR on a specific video frames, you can ask them to decode those frames as images and pass them to your SDK for recognition. However not only this would require extra work from the customer, but might also require them to learn new skills. Unlike moving the data buffers mentioned above – a trivial task – the customer might not be not necessary familiar with frame-based video processing. This would likely also require them to use extra libraries, raising potential support and licensing issues.
And even if you were incredibly smart, and implemented all needed functionality the first time – which is rare indeed – the new requirements might still arise tomorrow. For example, Amazon S3 or similar storage service opens up, and now your customers want you to be able to access the content directly from those services.
The goal here is to make sure you would be able to accommodate their requirements without breaking up the design of your SDK. This means new functionality should be organically integrated into the technology, and should not look out-of-place. This also means existing functions operating on data streams should be able to handle new data streams without changing the interface.