4 Tipps zur Auswahl und Evaluation von SaaS-Headless-Software

Komplexe Digitalisierungsinitiativen erfordern das Zusammenspiel verschiedener Softwarekomponenten. Die Zeiten, in denen diese sämtlich individuell für ein konkretes Projekt entwickelt werden, sind glücklicherweise lange vorbei. Ebenso unwahrscheinlich ist es jedoch, die eine ganzheitliche Lösung zu finden, die sämtliche geplanten Themenbereiche innerhalb eines Systems.

Deswegen sind SaaS-Systeme, die mit einer Headless-Schnittstelle ihre Funktionalität anbieten und sich mit anderen Systemen intelligent zu einer Gesamtlösung verknüpfen lassen, eine spannende Softwarekategorie. Auch diese Software sollte vor einer produktiven Nutzung und ggf. kostenpflichtiger Beschaffung entsprechend evaluiert werden. Der Vorteil einer ernstzunehmenden SaaS-Lösung sind die umfangreichen Möglichkeiten einer, schnell durchzuführenden, Evaluation.

Neben der reinen Überprüfung der angebotenen Funktionalitäten sind, aus meiner Erfahrung, in diesem Kontext vier Themenbereiche zu betrachten:

Real nutzbare Testversion

Caveat emptor gilt bereit in der altrömischen Rechtsprechung. D.h. der Käufer hat sich von der Funktionsfähigkeit/Mängelfreiheit des Produktes selbst zu überzeugen. Das schöne an SaaS-Software ist, dass der Aufwand selber eine konkrete Version der Software testen zu können gegen null tendiert. Sowohl beim Anbieter als auch bei Kunden selbst. Die Bereitstellung neuer Instanzen erfolgt beim Anbieter vollautomatisch, kundenseitig ist keinerlei Setup notwendig.

Insofern steht der Testversion rein logisch nichts entgegen. Für mich bedeutet dies: Eine SaaS-Software, für die eine Testversion nicht ohne weiteres bereit gestellt werden kann, fällt für eine weitere Evaluierung bereits aus.

Entweder sind die Betriebsprozesse nicht ausreichend automatisiert, was sich im späteren produktiven Betrieb sehr wahrscheinlich negativ auswirkt, oder aber es benötigt in der späteren Integration der Software doch noch einiges an Aufwand, um eventuelle Hürden zu umschiffen.

Konkret: Lass dir immer eine Testversion mit allen für dich relevanten Funktionen geben, mit der du für einen bestimmten Zeitraum eigenständig arbeiten kannst.

Öffentliche, vollständige API-Dokumentation

Enterprise-Software agiert immer im Zusammenspiel mit anderen Anwendungen. Daten werden ausgetauscht, Vorgänge automatisiert, etc. Die Qualität einer Enterprise-Software ist damit durch ihre Integrationsfähigkeit und dem Zusammenspiel mit anderen Anwendungen gegeben. Echter Nutzen ergibt sich meist erst, wenn man individuelle Prozesse, über mehrere Anwendungen übergreifend automatisiert.

Hier kommen die APIs ins Spiel und natürlich deren Zugänglichkeit.

Für mich: Eine öffentliche API-Dokumentation ist Pflicht. Diese muss allerdings auch eine entsprechende Qualität aufweisen. Dafür muss diese es erlauben, dass man selbst definierte Beispiel-Einsätze praktisch und ohne weitere Schulung/Einweisung durchführen können muss. Dass dabei die öffentliche, generelle API-Dokumentation exakt der Funktionsweise des bereitgestellten Testsystem abbildet sollte selbstverständlich sein.

Ein weiteres Kriterium für die APIs ist ihre Vollständigkeit: Eine Funktion, die nicht über eine API angesprochen werden kann, sondern einen manuell Bedienung erfordert, sollte als nicht existent angesehen werden.

Konkret: Definiere ein deine eigenen Beispiel-Einsätze und spiele diese anhand der Testversion und der API-Dokumentation praktisch durch oder lasse sie von einem technisch versierten Kollegen (ohne Schulung auf dem konkreten System) durchführen. Wenn dabei aufgrund von einer fehlenden API Schritte manuell durchgeführt werden müssen, ist der Test fehlgeschlagen.

Aktive Nutzung der API

APIs werden, wie alle Produkte, nur dann gut, wenn sie praxiserprobt sind, und das Feedback dieser Praxiserprobung seinen Weg in das Produkt findet.

Für die eine Software, die ihre API-Funktionalitäten etwa auch in einer Management-Oberfläche anbietet ist die Nutzung eigentlich bereits im Unternehmen des Anbieters gegeben. Da gibt es ja bereits eine Schnittstelle, um aus einer Oberfläche (hier die eigene Management-Oberfläche) Funktionen anzusteuern. Und noch besser: Das Feedback aus der Nutzung kann direkt intern weitergegeben werden.

Die Realität sieht leider nicht ganz so aus. Noch immer wird bei vielen Anbietern ein zweigleisiges Modell praktiziert, die interne Entwicklung für die Oberfläche hat einen eigenen, unabhängigen Weg mit der eigentlichen Software zu kommunizieren, die API wird lediglich durch die Kunden genutzt, intern werden kreative Abkürzungen verwendet. Damit wird die API diese automatisch zum Produkt zweiter Klasse, die Anpassungsfähigkeit und Integrationsfähigkeit der Software ist dahin.

Um ein Beispiel außerhalb der Software zu verwenden: Würdest du dein Obst bei einem Markthändler kaufen, der sein eigenes Obst aber verschmäht?

Konkret: Schau mal unter die Haube (geht mit modernen Tools sehr einfach), ob die schicke Pflegeoberfläche auch mit der öffentlichen API spricht.

Skalierung und Verfügbarkeit

SaaS impliziert auch die Abgabe des eigentlichen Softwarebetriebs, eine unter Last wenig performante Anwendung bzw. API kann auch mit hohem Individualaufwand nicht schneller gemacht werden.

Theoretisch sind hier Lasttests möglich, da eine SaaS-Platform aber für alle Kunden gleich aussieht und vom Anbieter betrieben wird, macht es hier Sinn, im Produktivbetrieb befindliche Referenzkunden zu kontaktieren und zu ihren Erfahrungen zu befragen.

Fazit

Die hier genannten Punkte sollen nicht den Eindruck erwecken, als wäre die Evaluation einer SaaS-Headless-Software besonders schwierig, oder komplex. Vielmehr zeigt sich, dass mit einfachen Schritten eine deutlich umfangreichere Evaluation erfolgen kann, als dies etwa bei einer klassischen Software mit vertretbarem Zeitaufwand möglich ist.