Was ist CLOUD SEVEN?

CLOUD SEVEN (kurz c7) ist zweierlei:

1. Stark vereinfacht: CLOUD SEVEN ist ein Tool für Softwareentwickler zur Nutzung einer zentralen Konfiguration. In der Regel dürfte es sich dabei um Softwarekonfiguration handeln, also die flexible Anpassung einer Anwendung an die Gegebenheiten der Systemumgebung oder der kundenspezifischen Anforderungen auf Basis diverser Parameter.
Im Gegensatz zu einer lokalen Konfiguration können sich mehrere Programme die Konfiguration ‘teilen’, was die Administration der Anwendungen und der Konfiguration stark vereinfacht.

2. CLOUD SEVEN bietet eine Benutzerverwaltung mit Benutzern, Gruppen, Aktionen und Rechten zur Einschränkung von Datenzugriffen, auch über die zentrale Konfiguration hinaus.

c7 steht als Java API (also als Framework bzw. Bibliothek) und als SOAP Server zur Verfügung. Zusätzlich wird derzeit an einer JMS Schnittstelle gearbeitet.

 

Was kostet CLOUD SEVEN?

CLOUD Seven existiert derzeit als Beta-Version. Diese Version kann kostenfrei von dieser Webseite herunter geladen werden.

Sobald CLOUD SEVEN aus der Beta-Phase heraus ist, werden zwei Lizenz-Varianten existieren. Voraussichtlich eine kostenlose Lizenz (möglicherweise mit eingeschränktem Leistungsumfang oder Datenvolumen) für Entwickler, die an nicht kommerziellen bzw. nicht kommerziell genutzten Programmen arbeiten und eine kostenpflichtige Lizenz für den Einsatz von c7 mit Gewinnabsicht.

 

Wie groß ist der Aufwand, um CLOUD SEVEN zu nutzen?

Antwort des Vertriebsmanns: ‘Extrem gering, kostet kaum Zeit und noch weniger Geld.
Antwort des Entwicklers oder Beraters: ‘Kommt darauf an.

Die folgenden Erläuterungen beziehen sich auf die Konfigurationsverwaltung. Für die Benutzerverwaltung stehen mir weder Vergleichs- noch Erfahrungswerte für seriöse Aussagen zur Verfügung.

Wenn Sie ein neues Softwareprojekt unter Java starten, ist der Implementierungsaufwand nach meiner Einschätzung zunächst geringfügig größer, als würden Sie mit anderen Standards arbeiten, beispielsweise Properties Files. Für lokale Konfigurationen sind wenige Funktionen notwendig, hinzu kommen allerdings die Installation, das Setup sowie die Einbindung der c7 Bibliothek. Sobald Sie die Vorteile einer zentralen Konfiguration nutzen wollen, liegt das Einsparpotential auf der Hand, da ja alle benötigten Methoden bereits implementiert sind. Besonders deutlich geringer fallen die Aufwände im Verhältnis zu Eigenentwicklungen aus, wenn Ihre Anwendung solche Punkte wie Mandantentauglichkeit, rechnerabhängige Konfiguration oder auch Caching berücksichtigen muss.

Ähnliches gilt für den Einsatz außerhalb von Java. Anstelle eines Frameworks kommt SOAP zum Einsatz. Das bedingt zwangsläufig entsprechende Kenntisse der Entwickler, sollte aber mittlerweile Teil des handwerklichen Könnens sein. Je nach Programmiersprache und Projektsituation ist der Aufwand eventuell etwas höher als unter Java, dürfte sich aber davon nicht deutlich unterscheiden.

Ganz anders verhält sich die Einschätzung für bereits bestehende Software. Hier kommt es beispielsweise darauf an, ob (noch) die Entwickler mit dem entsprechenden Know How verfügbar sind und wie die Software realisiert wurde.
Im besten Falle muss lediglich eine ‘Zwischenschicht’ in die Software eingezogen und c7 eingerichtet werden. Solche Arbeiten sind in der Regel in wenigen Stunden oder Tagen machbar.
Im schlechtesten Falle ist die Software – sagen wir – für eine Anpassung ungeeignet. Dann müssen viele Funktionen überarbeitet, ausgetauscht oder ergänzt werden. Je älter die Software, desto größer die Wahrscheinlichkeit, dass die Umstellung aufwändig wird. Was aber nicht bedeuten soll, dass alte Software zwangsläufig unsauber programmiert wurde!

 

Wir wollen eine bereits bestehende Software auf eine zentrale Konfiguration umstellen. Was bedeutet das?

Siehe letzter Abschnitt der Antwort auf die Frage ‘Wie groß ist der Aufwand, um CLOUD SEVEN zu nutzen?’

 

Worin liegt der Unterschied zwischen der Java API und den SOAP Services von CLOUD SEVEN?

Wie der Name schon sagt, ist die Java API ein Framework für Java-Entwickler.
Entwicklern, die eine Anwendung in einer anderen Programmiersprache implementieren oder anpassen sollen, bietet sich die SOAP-Variante an, da diese eine sprachunabhängige Schnittstelle ist.

Grundsätzlich bieten beide Alternativen zunächst die gleichen Möglichkeiten, wenn es um den Zugriff auf eine zentrale Konfiguration geht. Da über die API auch viele ‘interne’ Methoden von c7 verfügbar sind, haben Entwickler über das Framework noch mehr Handlungsspielraum. Allerdings sollte davon im Regelfalle kein Gebrauch gemacht werden, da die zentralen Methoden alle für die Konfiguration notwendigen Mittel offen legen.

Technisch betrachtet wird CLOUD SEVEN bei Verwendung der API ein fester Bestandteil der Software durch Einbindung des jar-Files, während unter Einsatz der SOAP Lösung c7 zentral installiert werden kann und der Zugriff über einen individuell zu implementierenden Teil erfolgt, den SOAP Client. Allerdings ist es auch möglich, den SOAP Server mehrfach, z.B. lokal, zu installieren.

 

Können Aussagen zur Performance, Skalierbarkeit oder Stabilität von CLOUD SEVEN getroffen werden?

Ja, Nein, Jain.

Ja zur Skalierbarkeit: Wenn c7 als SOAP Server genutzt wird, kann es parallel auf mehreren Servern installiert werden. Es handelt sich also um eine simple Lastverteilung.
Nein zu Performance und Stabilität: Für beides gibt es bisher nicht genügend Erfahrungen oder Testläufe. Allerdings ist Lastverteilung ein Weg, um die Verfügbarkeit zu sichern.
Jain: Performance, Skalierbarkeit und Stabilität hängen von mehr Faktoren ab, als nur von der Software selbst. Letztendlich müsste das im Einzelfalle überprüft werden.

 

Machen wir uns mit dem Einsatz von CLOUD SEVEN von einem Hersteller abhängig?

Ja.
Das machen Sie immer, wenn Sie nicht auf den (vorteilhaften) Einsatz von externen Frameworks bzw. Tools verzichten wollen oder können. Letztendlich trifft das ebenso auf den Einsatz von Standardsoftware zu. Selbst Open Source lebt davon, dass sich Entwickler finden, die daran arbeiten.

Anders herum: Je größer der Anteil eigenentwickelter Software, desto größer die Abhängigkeit vom Know How eigener Mitarbeiter. Ein weiteres großes Problem bei eigener Software ist die stete Pflege. Software soll der Optimierung von Produktions- oder Verwaltungsprozessen einer Organisation dienen. Bedingt durch Veränderungen, z.B. der Systemumgebung oder der eigenen Produktpalette bzw. angebotenen Dienstleistungen, muss Software laufend gewartet, ergänzt und erweitert werden. Damit verdient sich aber meist kein Geld, es kostet nur welches.
Standardlösungen haben den Vorteil des Multiplikators: Die  Kosten der Arbeiten an der Software teilen die Nutzer gewissermaßen untereinander auf. Und Hersteller von Software müssen zwangsläufig darauf achten, dass das Know How über die Software langfristig erhalten bleibt.

Gleiches gilt auch für die Entwickler von Standardsoftware. Was man nicht selbst programmieren muss, da es nicht Teil des Kerngeschäfts ist, kann man sich sparen :)

 

Was, wenn der Hersteller die Arbeiten an CLOUD SEVEN einstellt?

Das kann tatsächlich zum Problem werden. Die damit verbundenen Gefahren nehmen vermutlich mit der Größe des Unternehmens, das die Software einsetzt, zu.
Da diese Fragestellung für jede Fremdsoftware gilt, gibt es verschiedene Möglichkeiten der Vorbeugung. Eine Variante ist, zusätzlich zur kompilierten Software den Source Code einzukaufen oder bei einem Notar hinterlegen zu lassen, um die Software im ‘Notfall’ durch eigene Entwickler oder einen entsprechenden Dienstleister weiter pflegen zu lassen. Es gibt Anbieter von Standardsoftware, die den Code übernommen haben und unter eigenem Namen weiter entwickeln und vermarkten. Ein anderer praktikabler Weg kann aber auch die Offenlegung des Quellcodes (Open Source) sein, in der Hoffnung, dass sich genügend Entwickler mit Interesse daran finden.

 

Ich verstehe den Ansatz und die prinzipiellen Lösungswege, aber bieten Sie für Detailfragen darüber hinaus Beratung an?

Was spricht dagegen? Nehmen Sie Kontakt mit mir auf und wir reden über die Möglichkeiten einer Unterstützung. Vielleicht finden wir ja bereits in einem ersten Gespräch brauchbare Lösungsideen.

 

Wozu eine integrierte Benutzerverwaltung?

Ursprünglich war die Benutzerverwaltung gar nicht geplant. Mit der Idee einer Web-basierten Schnittstelle drängte sich zwangsläufig die Notwendigkeit des kontrollierten Zugriffs auf die Konfigurationsdaten auf.

Von Beginn an sollte die Konfigurationsverwaltung so flexibel sein, dass über die einfachen Key/Value Paare hinaus deutlich komplexere Anforderungen erfüllt werden können. Daher reizte mich zusätzlich zur o.g. Notwendigkeit die Herausforderung einer Implementierung der Benutzerverwaltung auf Basis der bereits größtenteils umgesetzten Konfigurationsverwaltung. Tatsächlich bedient sich die Benutzerverwaltung in großen Teilen der Konfigurations-API. Dennoch waren darüber hinaus einige spezielle Anforderungen direkt zu programmieren.