Is your SDK the Unwelcome House Guest?
Some manufacturers provide SDKs (software development kits) that feel a lot like a visiting cousin who outstays his welcome after a few days. All the pleasantries are there, the special towels are out and the good sheets have been fitted on the bed. But they are clearly a guest and not an embedded or integrated part of the family and after that fourth or fifth day, the signs are there that it’s time to move on.
An SDK that isn’t built to be assimilated into the product may make you feel pretty good at first (after all, we all feel good about ourselves when we let family stay with us). But, the best SDKs invite that cousin to become part of the family…complete with his own dresser, closet and parking spot in the driveway.
When we’re looking at manufacturer SDKs, we can tell immediately who is taking integration seriously, and who is really just in it to check off their good deed.
So, what do we look for in an SDK?
The right hooks. Even when a manufacturer documents their SDK, in most instances they demonstrate a simple use of a function as it applies to what already exists. But, since an integration partner will likely be adding new objects and functionality that will co-exist and interact with existing core product assets, the SDK owner should provide an example of an integration instead of showing a line or two of what already exists. For example, a sample application could show how to create a new object that has a user interface along with actions and messaging. It’s important to demonstrate how a new object can interact with existing objects, actions, and messages.
Clear definitions. One manufacturer calls it a Door, while another calls the same thing a Lock or a Portal. No two manufacturers call the process of providing a person permission to go through a door the same thing. Some have a name for it like “Access Level” or “Clearance”, while others don’t have a name at all, but simply an “under the hood” process. In order to be efficient, a manufacturer should have thorough documentation that helps the developer understand correct terminology.
Inclusion in the interface. Let’s face it. If you still have to toggle between your access control system and the other thing that’s integrated, it doesn’t feel all that integrated. A good SDK will let a developer add the integrated application right to the core interface of the access control system.
Many manufacturers provide APIs vs. SDKs, and we’re not saying a good API isn’t valuable. Using APIs is still effective in some instances where you just need to send or receive messages, or monitor alarms. The entire PSIM category was built on that philosophy. But when you and your customer are looking for a robust integration where the distinction between the two disparate products all but disappears, a well-documented SDK is the way to go.
So, clear out a closet and buy an extra table setting. It’s time to make that cousin a part of the family.