The Hidden Business Cost of SDKs

This article is full of technical jargon, but it’s not technical. It’s about how small technical decisions can have unexpected wild business impact. Its target audience is senior management.

Let me start by painting a rosy picture. You are a developer in a large organization GreatAdventures with millions of customers. You have been tasked with developing a mobile application that most of your customers will be using. As a part of requirements, you need to integrate the application with a vendor NiceFolks, let’s say for data analytics and marketing. You hosted a couple of meetings with the vendor and NiceFolks suggested that you can utilize their SDK. You went to their website and learned how easy the SDK is and how it will help you to decrease time to market and minimize costs at the same time. You also googled it and found out that 3rd parties say that generally “SDKs solve problems that the app’s developers couldn’t solve on their own.” You run a POC and everything is hunky dory. Your integration architecture is simple and looks like on the diagram below.

Time has passed, you have been happy with the vendor and you have done a great job improving the mobile application and now it supports iOS, Android and Windows, and there are more than a few versions out there in the wild. However, these demanding people from the business decided to “move your cheese.” They say that there is a new vendor SilverBullet that does this analytical and marketing magic so much better. Apparently, it’s critically important to switch the application to start using this new vendor. They said that the competition is already using SilverBullet and we are losing customers. You checked the new vendor’s website and found out that they offer an SDK too. Seems like an easy job and all you need to do is to release a new application version. But wait, remember, all versions that you have released are actively used in the wild? How on Earth are you supposed to force millions of users to upgrade to the new version? You feel like it’s time to start updating your resume! After calming down, you analyze the SDK and you realize that, in fact, all this SDK does is call NiceFolks’ RESTfull API and, lucky you, they use a dedicated domain GreatAdventures.NiceFolks.com.

So all you have to do is to build a RESTfull API that mimics NiceFolks’ API, make the API services to connect to the new vendor SilverBullet and somehow translate an API that is proprietary to the old vendor to a new vendor API.

This approach is not easy or pretty, but doable! It does not decouple your ecosystem from the old vendor completely as they own the DNS record, but it does allow you to switch your application to use the new vendor. You only have one small step to make, or, it’s actually your business that needs to make this step, it’s to convince the NiceFolks to update their DNS record to point to your Middleware API while you are moving away from them and keep it this way indefinitely!

What should have been done in the beginning, instead of using the vendor’s SDK, is to invest upfront in your own Middleware API that is vendor-independent. This approach would have decoupled your application from the vendor.

With this approach, you would have achieved: lower switching costs, increased bargaining power, and, most importantly, your technological readiness for taking advantage of new business opportunities. The developers have not done anything wrong, they never heard of switching cost. The business is not at fault either, they never heard of SDK or API or DNS. The decision back then was based on time to market and cost and it made everyone happy. The problem was the disconnect between long-term strategic business goals and technology solution. This gap is covered by an architect, usually a Solutions Architect.

This case is based on a real story, which is a fairly typical these days. The mobile application is a very good example, however, SDKs are not limited to the mobile world. Vendors want to lock you in and an SDK is one way to achieve this goal. There are other options at their disposal.

Solutions Architects are expensive resources and often overlooked as an impact from not involving them usually shows its ugly head later, sometimes years later, and performance is measured on a shorter term. However, this impact can be very costly. Don’t make the same mistake, invest into designing a solution that is right for your business, aligned with the org strategy, and sustainable.