Software Development Kits Still Play A Crucial Role in Technology Platform Growth

We have seen an explosion in the number of technology platforms over the past decade. Much of this growth is due to the availability of these platforms as internet-based services that don’t require their consumers to invest in hardware and software infrastructure necessary to deploy and host the platform. The other facet that has led to growth is the availability of application programming interfaces (APIs) based on Hypertext Transfer Protocol (HTTP), which facilitates rapid integration and consumption of the platform with a business’ existing application landscape.

However, many of these technology platform providers are remiss to also provide a software development kit (SDK) in addition to their APIs. SDKs provide a different function as they allow developers to extend the platform and add new features without vendor involvement. There’s good reason why many of these platform providers avoid providing SDKs; they provide access to platform internals and can cause detrimental consequences either purposefully or accidentally.

Microsoft Windows, Android-based devices, and Apple have been dealing with the repercussions of needing to provide an SDK for years. However, without an SDK, these platforms would not be as popular as they have become. A single vendor cannot anticipate the needs of billions of users. These platforms have grown because third-party developers have been extending these platforms via the SDK to provide missing functionality or enable add-on of new devices that entice users to the platform.

SDK vs. API

An argument can be made that if a technology platform is lacking in certain functionality it can be created external to the platform but still call the platform APIs to leverage the platform’s capabilities when required. In software engineering this is sometimes referred to as “wrapping”. New services can be developed that wrap other services creating more capable and intelligent layers. But only so much can be accomplished using this method.

Using wrapping developers will only have access to core data structures and the underlying data substrate that the platform provider makes available through the API. This is actually sound object-oriented design called abstraction and provides a modicum of protection to the underlying system. However, it also limits the types of actions that can be created. Even if the needed capability could be created using just APIs the performance of the resulting entity may not be usable.

Unfortunately, for technology platforms to go beyond what the original manufacturer envisioned they need to provide SDKs in addition to APIs. For example, I’ve used a number of Robotic Process Automation (RPA) platforms, but only one had an SDK. The others all required the bots to rely on external software to perform operations not provided with the RPA platform. This had the effect of making the bots slower and increased failures when a large volume of data needed to be passed.

Meanwhile, using the SDK I was able to extend the RPA platform to include new capabilities that could be included in a bot, that operated very efficiently, had access to the internal variable structures and simplified the development of bots significantly.

Conclusion

I truly believe that all technology platforms should provide both an SDK and APIs if they wish to see long-term growth of their platforms. Until a platform provider actually provides the SDK it is unlikely they will see innovation at scale that only comes with a third-party ecosystem extending the platform. It’s also important to provide a service to qualify applications that are developed using the SDK to ensure they don’t introduce security risks to their customers and that the new functionality will not introduce problems that will affect the viability of their platform.