CodeMeter Cloud: vom Pilotprojekt zum fertigen Produkt

Der Ursprung

Die Arbeit an CodeMeter Cloud begann bereits vor vier Jahren. Das Corporate Technology Team bei Wibu-Systems vergrößerte sich rasant und begann die Weichen bei Wibu-Systems für die Softwarelizenzierung der Zukunft zu stellen.

CmDongles und CmActLicenses würden natürlich weiter benötigt werden, aber Mobilität würde das Paradigma in der neuen, zukünftigen Arbeitswelt werden. Echte Flexibilität in Echtzeit war die Anforderung – und die Idee der CmCloud war geboren.

Wibu-Systems bietet bereits ein ungeschlagen sicheres donglebasiertes Lizenzierungssystem mit Möglichkeiten für Netzwerklizenzen. Darüber hinaus gibt es mobilere und nur minimal weniger sichere aktivierungsbasierte Lizenzen. Unsere Kunden entwickeln sich jedoch ebenfalls immer weiter, d.h. ihre Anforderungen und ihre ganzen Arbeitswelten werden immer komplexer. CmCloud wurde entwickelt, um ihnen völlige Flexibilität zu ermöglichen.

Das Pilotprojekt

Bei Wibu-Systems ist uns viel daran gelegen, dass unsere Lösungen die tatsächlichen Anforderungen unserer Kunden abdecken. Wir sind nicht hier, um Produkte zu entwickeln und erst dann dem Kunden zu erklären, warum er sie überhaupt haben möchte. Wir wollen wissen, was genau unsere Nutzer bewegt, warum das so ist oder welchen Herausforderungen sie sich gegenüber sehen, lange bevor wir mit der Entwicklungsarbeit beginnen.

Fast jeder erfahrene Softwareentwickler wird schon einmal an einem Projekt teilgenommen haben, in dem Funktionalitäten entwickelt wurden, die später nicht im Feld eingesetzt wurden. Das kann dann passieren, wenn Annahmen ungenau aus realen Kunden- und Marktanforderungen abgeleitet werden. Ein symptomatischer Satz ist dabei: „Das ist eine tolle Idee – da hat der Kunde einfach noch gar nicht dran gedacht.“ Ich habe es selbst oft erlebt, dass verschiedene Entwickler in ihren Teilen der Software ohne konkrete Anforderung neue Funktionen eingebaut haben, da diese nach Meinung des Entwicklers sicherlich in absehbarer Zeit nützlich werden würden. Aber nicht so wie Wibu-Systems.

Wir sprechen von Funktionen, deren eigentlicher Einsatzzweck nicht spezifiziert wurde. Das ist aus vielen Gründen keine gute Idee:

• In moderner Software wird zwar alles modular und gekapselt entwickelt, aber dennoch gibt es Unwägbarkeiten im Zusammenspiel der verschiedenen Module. Warum also ohne Not weitere Unwägbarkeiten einfügen?
• Entwicklerarbeit kostet Geld. Geld, das sich irgendwann negativ in den Portemonnaies der Endnutzer bemerkbar machen wird.
• Die Entwicklung benötigt Zeit, während der die tatsächlich benötigten Funktionen dann nicht bzw. erst später implementiert werden können.
• Aller Code braucht Support, Dokumentation und viel Wartungsaufwand. Dies ist ein Kostenfaktor, der vorsichtig abgewogen werden sollte.

Der Sinn unseres Pilotprojekts war es, herauszufinden, was unsere Kunden tatsächlich benötigen. Damit meinen wir keine eng umschriebenen Anforderungskataloge, sondern ein genaues Verständnis der Welt, in der unsere Kunden arbeiten und der Arbeitsabläufe, die dort eingesetzt werden.

Der Prozess

Wir begannen damit, einen Musterprozess für unsere Arbeit mit den Pilotkunden zu erstellen. Damit konnten wir sicher sein, dass wir nichts vergessen hatten, und es gab eine Grundlage für spätere Optimierungen. Es würden ja noch weitere Kunden dazukommen, und wir wären auf deren Fragen und Probleme vorbereitet.

Der Aufbau

Lange bevor ich als Produktmanager für CmCloud mit unseren Kunden an die Arbeit gehen konnte, mussten noch einige Themen geklärt werden. Dazu gehörte natürlich auch der unvermeidliche Papierkrieg, wie z.B. Ergänzungen und Anpassungen der gegenseitigen Geheimhaltungsvereinbarungen (NDAs) zwischen uns und unseren Kunden.

Der nächste Schritt war die Herstellung der Dongles, und hier ging es endlich zur Sache. Sicherheit ist uns wichtig bei Wibu-Systems. Wir teilen jedem Kunden eine eigene Firm Security Box (FSB) mit den Verschlüsselungsfunktionen zu, mit denen unsere Kunden ihre Software schützen und Lizenzen erstellen können. Das System ist so komplex und so sicher, dass nicht einmal wir selbst Lizenzen für die Software unserer Kunden erstellen können. Das können nur sie – aber gerade für unser Pilotprojekt mussten auch wir das tun, um CmCloud live zu testen.

Jedem Kunden wurden dazu vier Dongles zugeteilt, die jeweils verschiedene Funktionen der normalen FSBs abbildeten und mit unterschiedlichen Zertifikaten an die eigentlichen FSBs der Kunden gebunden waren. 

Erstkontakt

An den ersten Online-Meetings mit unserem Kunden nahmen immer Dr. Björn Grohmann, Leiter Corporate Technology bei Wibu-Systems, und ich selbst teil. Wir erklärten, warum wir CmCloud überhaupt entwickelt haben und führten eine kleine Musteranwendung vor. Björn Grohmann hatte diese geschrieben, um zu zeigen, wie CmCloud deren Nutzung aus der Ferne und in Echtzeit steuern kann.

Dies lässt sich am einfachsten per Lizenzanzahl (License Quantity oder LQ) darstellen. Dieser Parameter bestimmt, wie viele Instanzen der Anwendung gleichzeitig laufen können, bevor CmCloud eine weitere Ausführung untersagen würde. Mit LQ=1 darf die Anwendung nur von je einem Nutzer verwendet werden, LQ=3 erlaubt drei parallele Nutzungen und so weiter. CmCloud unterstützt alle Lizenzoptionen von CodeMeter, so dass alle erdenklichen Lizenzmodelle ebenfalls abgebildet werden können, bspw. ein Abo-Modell über das Verfallsdatum (Expiration Time) oder Pay-Per-Use mit Nutzungseinheiten (Unit Counter).

Projektverlauf

Ich hatte eine Einführung geschrieben, die unseren Pilotkunden einen fliegenden Start mit CmCloud ermöglichte. Und tatsächlich: Alle Teilnehmer arbeiteten problem- und reibungslos mit CmCloud. Das ist besonders wichtig für mich als Produktmanager: Eine Software sollte sich immer so einfach wie möglich anfühlen. Tiefer liegende Probleme kann man immer noch lösen, aber Unannehmlichkeiten oder einfach ein schlechtes Feeling beim Nutzer sind nie ein gutes Zeichen.

Wir hatten uns ursprünglich auf einen vierzehntägigen Sitzungsrhythmus eingestellt, abhängig von den Erwartungen und der Verfügbarkeit des Kunden. Nach einer Weile wurden daraus jedoch einfach Ad-Hoc-E-Mails, mit denen wir sicherstellen konnten, dass alle Teilnehmer zufrieden waren und keine Probleme hatten.

Um Feedback haben wir bei jeder Gelegenheit gebeten. Positive Rückmeldungen fühlen sich natürlich immer gut an, aber konstruktive Kritik kann noch viel wertvoller sein. Wir brauchen sie, um die Software zu verbessern – was immerhin der Sinn des kompletten Pilotprojekts war.

Das Feedback

The Good

Die folgenden Statements sind eine direkte Übersetzung des Feedbacks echter Kunden, natürlich in anonymisierter Form – Datenschutz fängt zuhause an.

"Es gefällt mir. Es sieht einfach cool aus.“

"Das sieht sehr gut aus. Ich kann <das Hauptprodukt des Kunden> ganz wie gehabt nutzen … Ein erster Leistungscheck hat auch sehr gute Ergebnisse gezeigt.“

"Es freut mich, wie einfach wir es integrieren konnten.“

"Das Konzept hat viel Potenzial … eine echte Lösung für Lizenzen in virtuellen Umgebungen.“

The Bad

Im Pilotprojekt entdeckten wir einzelne Punkte, in denen CmCloud nicht ganz den Anforderungen entsprach. Wir haben diese Aspekte genau erfasst und priorisiert, ist es doch unser ursprünglicher Anspruch, dass unsere Software das tut, was unsere Kunden tatsächlich erwarten.

"Der Proxysupport könnte besser sein“, war wohl die am häufigsten genannte Kritik. Es gibt so viele unterschiedliche Netzwerke mit so vielen unterschiedlichen Arten von Proxies auf so vielen unterschiedlichen Plattformen. Dies alles abzudecken ist eine Herkulesaufgabe, daher war hier jeder Hinweis von unschätzbarem Wert für uns. Letztlich haben wir es geschafft, CmCloud problemlos in proxy-basierten Umgebungen zum Laufen zu bringen.

Wir hörten auch immer wieder den Ruf nach mehr Berichtsfunktionen. Es scheint trivial zu sein, aber dies ist eigentlich ein eigenes Produkt mit ganz eigenen Herausforderungen. „Berichtsfunktionen“ kann so viel bedeuten. Wir hatten schon erwartet, dass irgendeine Form von Berichten erwartet werden würde; daher war es gut, unsere Annahme bestätigt zu sehen. Wir haben verschiedene Möglichkeiten entwickelt, die dem Nutzer erlauben, zu sehen, wie viele Instanzen einer Lizenz aktiv sind. Und unsere Arbeit geht weiter.

"Wir bräuchten für Großkunden die Möglichkeit, Credentials zu verwalten“, war ebenso ein oft gehörtes Argument. Dies ist wieder ein ungemein wichtiges Thema – das einen eigenen Artikel im KEYnote-Magazin verdient – aber ich kann schon verraten: Wir arbeiten daran.

The Ugly 

Nichts zu berichten: CmCloud läuft so sicher und stabil, wie wir es erwartet hatten.

Ein Fazit

Man kann mit Sicherheit sagen, dass unser Pilotprojekt ein Riesenerfolg war und immer noch ist (wir nehmen weitere Pilotkunden an). Es liegt mir immer sehr viel daran, mit unseren Kunden persönlich über unsere Produkte zu sprechen. Ich will wissen, wo es bei ihnen zwickt, damit ich jedes Problem ausbügeln kann. Auch persönlich war daher das Pilotprojekt ungemein wichtig und ein großer Erfolg: Ich konnte unsere Kunden noch viel näher kennenlernen.

CmCloud wird im Dezember in die freie Wildbahn entlassen werden. Dank des immens wichtigen Feedbacks unserer Pilotkunden wird es noch besser sein als wir erhofft hatten – und dafür gilt allen Teilnehmern mein Dank!

 

KEYnote 38 – Herbstausgabe 2019