Software darf keine Insel sein

Kennen Sie den Satz „unsere Stärke ist, dass wir unsere Software auf unsere Kunden anpassen können“? Das habe ich vor 10 Jahren auch noch gedacht – und bin damit gescheitert (unsere Software damals hieß „miX-L TV“).

Mittlerweile weiß ich, dass diese Meinung fundamentale Gesetze des Marktes und der Softwareentwicklung ignoriert und letzten Endes nur scheitern kann, es sei denn, man kann die Software in einer perfekten Nische positionieren.

Digital Signage Software should not be an Island

Vielleicht kam man damit durch, als eine DS Lösung noch so aussah:

• User
• CMS
• Player

Heute aber sehen DS Netzwerke so aus:

• Viele User
• CMS der DS Software
• CMS des Kunden
• Web Applikationen
• Multi Channel Marketing
• Cloud
• Mobil
• Social Media
• Internet Of Things
• Sensoren
• Andere integrierte
  Lösungen (SAP,
  Salesforce…)
• Prozesssteuerung
• Smart TV / SoC

Kennen Sie den Satz „Unsere Software kann alles“? Sehen Sie sich die obere Grafik noch einmal an – ich glaube das einfach nicht. Und es wäre auch vollkommen sinnlos und Ressourcenverschwendung, alles zu können.

Kennen Sie den Satz „Unsere Software kann die 80%, die für die meisten Projekte reichen.“? Auch diese Aussage ist gefährlich, da sich die 80% beständig ändern und im Rahmen der Globalisierung und Konsolidierung kann Ihre Software mittlerweile eher 40%.

Für einen dauerhaften Erfolg sind alle drei Aussagen – Anschauungen – zumindest gefährlich.

Dabei ist die Lösung für alle diese Probleme ganz einfach: API.

In unserer vernetzten Welt, in der Daten bares Geld bedeuten und die Big 5 der Weltökonomie vom Austausch von Daten leben, bedeuten APIs bares Geld. Was wäre Google ohne APIs? „Was hat Google denn an APIs?“. Das wissen Sie vielleicht nicht, aber ich wette, dass Sie mit Ihrem Handy täglich Hunderte von APIs nutzen, ohne das überhaupt zu merken.

Schnittstellen / APIs in Digital Signage ist ein kritisches Thema. Viele Anbieter – Digital Signage CMS als auch Integratoren – unterschätzen das Thema Standards in Schnittstellen zu Drittsystemen. invidis wird in den kommenden Wochen einige Artikel und Hintergrundberichte zum Thema Schnittstellen veröffentlichen.

Mit Florian Bogeschdorfer haben wir einen Experten für die technischen Hintergrundartikel gewinnen können. Bogeschdorfer ist Geschäftsführer der DS Connekt GmbH, die sich auf Programmierungen und technische Beratung im Bereich Digital Signage spezialisiert und schon für viele führende Integratoren und Softwareanbieter tätig war.

Florian Bogeschdorfer entwickelte bereits 1993 die Software für eines der allerersten DooH-Netzwerke.

Was ist denn eine API eigentlich?

API bedeutet schlicht „Application Programming Interface“ – also eine Schnittstelle zu einer Software, über die sich andere Softwares andocken kann. Dabei ist die API an sich keine neue Erfindung, denn ohne sie gäbe es keine Netzwerke, kein Windows, kein Facebook oder Google, kein Internet, noch nicht einmal IHRE eigene Software. Und wenn Sie jetzt sagen „das ist eine Sache der Entwickler“, dann machen Sie einen Fehler. API ist ein Thema für Geschäftsleitung, Marketing, Vertrieb, Human Resources und Produktentwicklung.

Die Vorteile einer guten API sind:

• Funktionalitäten werden in eigene Bereiche getrennt, die für sich wesentlich einfacher zu warten und zu verwalten sind
• Dritte können mit ihrer ganzen Manpower Features and Problemlösungen entwickeln, ohne dass der Softwarehersteller dafür bezahlen muss
• Die Integrationsmöglichkeiten mit einer Vielzahl anderer Software-Systeme erschließen neue Kunden und Märkte
• Programmierarbeiten können einfach an Subunternehmer ausgelagert werden, wenn Sie keine Kapazitäten frei haben oder Spezialisten benötigen
• Die Instandhaltungskosten über die Jahre verringern sich während die Leistungsfähigkeit Ihrer Software und deren Stabilität und Qualität steigt

Natürlich kann nicht alles in APIs ausgelagert werden – irgendwas müssen diese APIs ja auch steuern können. Trotzdem greifen auch heute noch viele Firmen grundsätzlich zum Custom Feature Development, statt sich zu überlegen, ob eine gute API nicht sinnvoller wäre.

Nehmen wir als Beispiel mal einen Content Editor – Projekt X benötigt einen WYSIWYG Content Editor, mit besonderer Rechteverteilung und ganz tollem Design. Eine schlechte Entscheidung wäre genau das zu entwickeln und so zu integrieren. Das ließe sich verbessern, indem man versuchte die Anforderung zu abstrahieren und damit auch für andere nutzbar zu machen. In beiden Fällen aber landen Sie innerhalb weniger Jahre und weniger Projekte bei diversen Servern, die unterschiedliche Funktionen haben, umfangreichen „IF“ Konstrukten und schlecht gewartetem Code, der bei jedem Update zu unkontrollierbarem Chaos führt.

Denn Projekt Y benötigt viel weniger Editor und will alles ganz einfach. Wieder wird alles komplizierter, Ihr Chefentwickler verlässt frustriert das Unternehmen und Sie stehen vor einem Refactoring, dass sie ein ganzes Jahr kosten wird.

Eine einfache API zwischen Content Management und User Interface hätte all das lösen können. Projekt X und Y hätten eigene User Interfaces bekommen, Projekt E und F brauchen kein User Interface, sondern hätten den Content per SAP, Salesforce und Buchungssystem hinzugefügt und Projekt Z macht etwas ganz Tolles, auf das Sie selbst nie gekommen wären. Auf einmal ist die Software für alle gut genug.

Die Kosten über die Jahre sind wesentlich geringer, da Ihre API vielseitig nutzbar ist und nur geringen Wartungsbedarf hat im Gegensatz zum Custom Feature Development, bei dem Sie immer wieder für die Entwicklung bezahlen und die Wartung Ihres Codes irgendwann den größten Betrag ausmacht.

Erfolgreiche Software ohne eine API ist heutzutage ein Ausnahmeprodukt – je besser die API, desto mehr Möglichkeiten in der Verwendung der Software, desto mehr Integrationsmöglichkeiten in bestehende Infrastrukturen und desto weniger Features müssen z.B. zum Ausspielungsmanagement neu – wieder – entwickelt werden. Aber wie muss sie sein und was macht eine gute API aus? Und wie verhilft sie Herstellern und Integratoren zu mehr Umsatz?

Das lesen Sie in unserem zweiten Teil.