SDK

Was ist ein SDK?

SDK (Software Development Kit, Softwareentwicklungspaket) bezeichnet eine Sammlung aus Programmbibliotheken, Dokumentation, Beispielcode und Werkzeugen für Entwickler. Programmbibliotheken sind fertige, wiederverwendbare Programmbausteine. Mit einem SDK erstellen Entwickler Software für eine bestimmte Plattform oder binden einen fremden Dienst in ihr eigenes Produkt ein. Anders als eine Web-Schnittstelle, die auf den Servern des Anbieters läuft, wird ein SDK in die Software des Nutzers eingebaut und mit ihr ausgeliefert. Man kann es sich als Bausatz vorstellen: Statt jedes Teil selbst zu fertigen, erhält der Entwickler vorgefertigte Teile mit Bauanleitung, die zu genau einem System passen.

SDKs gibt es in zwei Grundformen. Plattform-SDKs stellen Hersteller von Betriebssystemen oder Geräten bereit, damit Dritte Anwendungen dafür entwickeln. Dienst-SDKs bieten Anbieter von Zahlungs-, Analyse- oder Identitätsdiensten an, um die Anbindung an ihre Programmierschnittstelle (Application Programming Interface, API) zu vereinfachen. In Finanzierungsrunden und Unternehmensverkäufen interessiert das SDK als Vertriebsinstrument, als eigenständig lizenziertes Produkt und als Quelle von Abhängigkeiten und Datenflüssen.

Aufbau und Verhältnis zur API

Ein SDK enthält typischerweise fertige Funktionen für die wichtigsten Aufrufe eines Dienstes, die Verwaltung von Zugangsdaten, eine verständliche Fehlerbehandlung, Beispielanwendungen und häufig eine Testumgebung ohne echte Daten. Es wird für jede unterstützte Programmiersprache oder Plattform gesondert erstellt, etwa für mobile Betriebssysteme, Webanwendungen und Serversoftware.

Die Programmierschnittstelle legt fest, welche Anfragen ein Dienst annimmt. Das SDK nimmt dem Entwickler ab, diese Anfragen selbst zusammenzusetzen. Das verkürzt die Integrationszeit erheblich, macht den Kunden aber auch von Versionen und Pflege des SDK durch den Anbieter abhängig.

Geschäftsmodelle

• SDK als Vertriebsinstrument: Das SDK ist kostenlos, abgerechnet wird die Nutzung des Dienstes dahinter. Je einfacher die Einbindung, desto mehr Integrationen entstehen und desto höher sind die Wechselkosten der Kunden.
• SDK als Lizenzprodukt: Das SDK selbst wird lizenziert, etwa je Anwendung, je Gerät oder je aktivem Nutzer. Verbreitet ist das bei Funktionen, die lokal auf dem Gerät laufen, etwa Bildverarbeitung oder Dokumentenerfassung.
• SDK als Teil einer Plattform: Plattformbetreiber stellen SDKs bereit, damit Dritte ihr Ökosystem erweitern. Mehr Drittanwendungen ziehen mehr Nutzer an und umgekehrt; es handelt sich um indirekte Netzwerkeffekte.

Jede unterstützte Sprache verursacht dauerhaften Aufwand für Veröffentlichungen, Tests und Sicherheitsaktualisierungen. Für die Bewertung zählt deshalb weniger die Zahl der Sprachen als die Zahl aktiver Integrationen und deren Entwicklung über die Zeit.

Lizenz, Haftung und Datenschutz

Weil das SDK mit der Software des Kunden an Endnutzer verteilt wird, braucht der Kunde ein Nutzungsrecht, das diese Weitergabe abdeckt. Die Lizenzbedingungen regeln, in welchen Produkten das SDK verwendet werden darf, ob Änderungen zulässig sind und was bei Vertragsende gilt. Enthält das SDK Open-Source-Bestandteile, gelten deren Lizenzpflichten bei jeder Weitergabe, also beim Anbieter und bei jedem Kunden, der das SDK mit seiner App ausliefert. Besonders heikel sind Bausteine unter strenger Copyleft-Lizenz. Solche Lizenzen erlauben die Weitergabe darauf aufbauender Software nur, wenn auch deren Quelltext offengelegt wird, also der lesbare Programmcode dahinter. Kunden müssten dann eigenen Quelltext freigeben oder das SDK entfernen, was für einen SDK-Anbieter ein erhebliches Geschäftsrisiko ist.

Wer fremde SDKs einbaut, trägt deren Risiken mit. Analyse- und Werbe-SDKs in Apps lesen häufig Informationen auf dem Endgerät aus und übermitteln Daten an Dritte. Der Zugriff auf das Endgerät ist nach § 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) grundsätzlich nur mit Einwilligung zulässig, soweit er für den gewünschten Dienst nicht unbedingt erforderlich ist. Für die Weitergabe der Daten gelten zusätzlich die Anforderungen der Datenschutz-Grundverordnung. Eine Sicherheitslücke in einem verbreiteten SDK betrifft jede Anwendung, die es enthält, während die Haftung des Anbieters in seinen Lizenzbedingungen meist eng begrenzt ist.

Prüfung in der Due Diligence

Bietet das Zielunternehmen selbst SDKs an, prüfen Käufer und Investoren in der Due Diligence, der Untersuchung vor der Transaktion, vor allem:

• die Lizenzbedingungen gegenüber Kunden, einschließlich Haftungsbegrenzung und Übertragbarkeit,
• eine Software-Stückliste (Software Bill of Materials), also eine Aufstellung aller enthaltenen Fremdkomponenten mit Version und Lizenz,
• die Zahl aktiver Integrationen und den Anteil der Installationen auf gepflegten Versionen,
• den Ablauf von Sicherheitsaktualisierungen und die Geschwindigkeit, mit der Kunden sie übernehmen.

Nutzt das Zielunternehmen fremde SDKs, gehören eine Übersicht mit Anbieter, Zweck, Lizenz und Datenflüssen sowie die zugehörigen Verträge in den Datenraum, die geschützte Dokumentensammlung für die Prüfer.

Praxisbeispiel

Ein Softwareunternehmen bietet die automatische Erfassung von Ausweisdokumenten an. Banken, Versicherungen und Vermietungsplattformen bauen sein SDK in ihre Apps ein. Abgerechnet wird je erfolgreicher Prüfung über die Schnittstelle, das SDK selbst ist kostenlos. Rund 120 Kunden haben es eingebaut, die Zahl aktiver Integrationen ist im Vorjahr um 30 % gewachsen. Ein strategischer Käufer, also ein Unternehmen derselben oder einer benachbarten Branche, prüft das Unternehmen vor einer Übernahme.

• Die Software-Stückliste zeigt im SDK für mobile Geräte eine Bildverarbeitungsbibliothek unter einer Copyleft-Lizenz. Das Unternehmen ersetzt sie vor dem Signing (Unterzeichnung des Kaufvertrags) durch eine Komponente unter freizügiger Lizenz.
• Rund 40 % der aktiven Installationen laufen auf Versionen, die älter als zwei Jahre sind und keine Sicherheitsaktualisierungen mehr erhalten. Der Käufer verlangt einen Plan, mit dem diese Kunden innerhalb eines Jahres umgestellt werden.

Im Kaufvertrag sichert sich der Käufer über eine Garantie zur Einhaltung aller Open-Source-Lizenzen und eine Freistellung für Ansprüche aus dem ersetzten Baustein ab. Die Zahl aktiver Integrationen und ihr Wachstum fließen als Beleg für Kundenbindung in die Bewertung ein. Keiner der Befunde gefährdet die Übernahme, beide hätten sich aber mit einer gepflegten Stückliste und einer Regel für das Abschalten alter Versionen schon vor dem Verkauf erledigen lassen.

Abgrenzung zu verwandten Begriffen

• API: die Schnittstelle, über die ein Dienst angesprochen wird. Sie bleibt beim Anbieter; das SDK ist das Hilfsmittel auf Seiten des Kunden, das diese Schnittstelle bedient.
• Programmbibliothek: ein einzelner Baustein mit wiederverwendbarem Code. Ein SDK enthält meist mehrere Bibliotheken, ergänzt um Dokumentation, Beispiele und Werkzeuge.
• Programmiergerüst (Framework): gibt den Aufbau einer ganzen Anwendung vor. Ein SDK wird dagegen in eine bestehende Anwendung eingefügt.

Typische Fehler

• Zu viele Plattformen zu früh. Mehrere unzureichend gepflegte SDKs verursachen mehr Supportaufwand und Sicherheitsrisiken als ein einziges, das zuverlässig funktioniert.
• Fehlende Übergangsfristen. Wer alte SDK-Versionen ohne Vorlauf abschaltet, unterbricht die Anwendungen der Kunden und gefährdet Vertragsverlängerungen.
• Keine Übersicht über Fremdkomponenten. Ohne Software-Stückliste lässt sich nicht belegen, welche Lizenzpflichten mit dem SDK an Kunden weitergegeben werden.
• Unbekannte Datenflüsse. Unternehmen, die Analyse- oder Werbe-SDKs einbauen, ohne deren Datenübermittlung zu kennen, gehen datenschutzrechtliche Risiken ein.
• SDK getrennt vom Produkt entwickelt. Hält das SDK mit der Schnittstelle nicht Schritt, fehlen neue Funktionen, und Kunden weichen auf eigene Anbindungen aus.

Häufige Fragen

Braucht jedes Softwareunternehmen ein eigenes SDK?

Nein. Ein SDK lohnt sich, wenn Entwickler die Zielgruppe sind oder Kunden den Dienst in eigene Software einbauen. Bei Produkten, die ausschließlich über eine Oberfläche bedient werden, steht der Pflegeaufwand selten im Verhältnis zum Nutzen.

Lassen sich SDKs automatisch erzeugen?

Teilweise. Aus einer maschinenlesbaren Schnittstellenbeschreibung lassen sich SDKs für mehrere Sprachen weitgehend automatisch erstellen. Das senkt den Pflegeaufwand, das Ergebnis ist aber oft weniger komfortabel als ein von Hand gestaltetes SDK.

Woran lässt sich die Qualität eines SDK messen?

Am aussagekräftigsten ist die Zeit vom ersten Aufruf der Dokumentation bis zur ersten erfolgreichen Anfrage. Ergänzend zählen Supportanfragen je Integration und der Anteil der Kunden auf aktuellen Versionen.

Darf ein Kunde ein SDK nach Vertragsende weiter nutzen?

Das regeln allein die Lizenzbedingungen. Manche SDK-Lizenzen enden mit dem Dienstvertrag, andere gewähren ein unbefristetes Nutzungsrecht an der ausgelieferten Version. Wirtschaftlich erheblich ist das vor allem bei SDKs, die auch ohne die Schnittstelle des Anbieters funktionieren.

Roemer Capital Perspektive

Bei Mandanten, deren Wachstum auf Integrationen beruht, gehört die Zahl aktiver Integrationen je Kunde in das Finanzmodell und in die Equity Story. Gemeint ist damit die wirtschaftliche Begründung des Einstiegs gegenüber Investoren und Käufern. Die Zahl belegt Wechselkosten besser als jede Beschreibung der Technik.

Vor Beginn eines Verkaufsprozesses klären wir mit dem Mandanten, ob für jedes ausgelieferte SDK eine Software-Stückliste vorliegt und wie viele Kunden noch auf veralteten Versionen arbeiten. Beides lässt sich kurzfristig kaum ändern. Liegen die Zahlen früh vor, kann die Kanzlei des Mandanten Garantien und Offenlegungen im Kaufvertrag darauf abstimmen, statt unter Zeitdruck nachzuarbeiten.