If you are a software developer, more than likely at one time or another, you have used a SDK. Software Development Kit, or SDK, is a collection of related software components and tools that enables one to create new applications. Major operating system vendors, like Microsoft and Google, release SDK to enable a community of developers to write new applications, thereby adding value to their ecosystems. SDK is not just for operating systems vendors; similar ecosystem strategies are used by other companies to add values to their core products.
While SDKs are used by many, less known is how SDKs are created. In this two-part article, I will share my experiences in the SDK creation process. Part 1 of this article discusses the benefits and key design principles of SDK. In Part 2, I will offer some SDK design considerations, including architecture, file structure, development process and distribution.
SDK is like a LEGO set – a collection of building blocks …
Every time I walk by a LEGO store I am fascinated by the models on display – each having an amazing level of detail, made with thousands of LEGO blocks. On one such occasion, it dawned on me that SDK is like a LEGO set – a collection of building blocks that enables others to create something more complex and beautiful. The building blocks are meticulously designed to have different functions and standard interfaces so that they can be recombined in different ways limited only by one’s imagination.
Just as a LEGO model of Empire Destroyer is built from the combined creativity of the LEGO maker and the model builder, so is full-featured software application built from the combined creativity of the SDK creator and the application author. Well-structured SDK supports mixing of creativity from various sources while preserving the intellectual property rights of all contributors. In SDK, intellectual property and creative rights are protected by distributing SDK components as linkable library files and license agreements.
SDK supports mixing of creativity from various sources …
Just as LEGO building blocks have standard mating interfaces allowing the builder to assemble them into complex models, properly partitioned SDK components should export standard interfaces to allow SDK components and the user application to interoperate, and the user application can pull in only the components it needs.
Components with Standard Interfaces
Component modularity means that each SDK component can be unit-tested and deployed, and therefore have its own quality heritage. User applications containing significant field-qualified SDK components will have greater initial quality going into the test phase, therefore a shortened test time can be expected.
In my article, Creating Value in Software, I discussed various ways developers can add value to their software. One of the best ways to build value into software is to design the software for other people to use. If you think about it, what is the value of a brilliant piece of software if it is inaccessible? Accessibility is not just availability, but also ease-of-use. Software that is available, but hard to use, also has diminished value.
SDK is, by its very nature, software designed for others to use.
SDK, by its very nature, is software designed for others to use. Ease-of-use can be imparted into a SDK at many levels. At the source code level, the SDK should follow a consistent, easily readable coding style, and have clear and concise comments. At the design level, the SDK should have a modular, object-oriented architecture that localizes the impact of changes. At the application level, the SDK should include example code to show how the components are used. In summary, SDK should be designed based on the principle of making it easy for others to use.
… SDK as a Business Strategy
Business executives have long used SDK as a business strategy. SDK are used to create tailored solutions for different customers, and shared with third-parties so that they can add new values around the core products. New features added by third-parties will expand the solution portfolio of the core products, broadening the product’s market appeal. Third-party software can be co-marketed with the company’s core products. The community of customers, third-parties and even individual developers of the SDK form an ecosystem that can further promote the core products.
In Part 2, I will discuss SDK design considerations, including architecture, file structure, development process and distribution. Click “Follow” to receive notification when Part 2 is published, or check back this page for a link to Part 2.
Further Readings:
(The above article is solely the expressed opinion of the author and does not necessarily reflect the position of his current and past employers)
I will be looking forward for second part and also will be interested in how to package all these things (SDK + examples) in installer format (MSI) so that we can easily distribute it to end users.
Horaira – thank you for your comment. I hope you enjoyed Part 1 of this article. Part 2 is more extensive and I expect to publish it in a few days.