In einem anderen Artikel haben wir über Software-Einführungen gesprochen und Ihnen die Frage gestellt, ob Ihre Unternehmung beim Einkauf auf Standard-Lösungen setzt. Hier geht es nun um die Frage: Müssen wir bei Standard-Lösungen auf Anpassbarkeit verzichten? Und: Was versteht man unter konfigurierbarer Software?

Standard-Software: Viele Begriffe – ein Prinzip

Fangen wir mal vorne an. Wir entscheiden uns für den Kauf einer sogenannten Standard-Lösung. Was ist das überhaupt? Dazu gibt es bestimmt verschiedene Meinungen, genau so wie verschiedene Begriffe, z.B. Out-of-the-Box oder Commercial Off-the-Shelf (COTS) Software. Wir definieren hier eine Standard-Software primär mit Bezug auf die Art und Weise, wie die Software vom Lieferanten entwickelt und gepflegt wird.

Die Entwicklung einer Standard-Software verläuft zeitlich entlang eines einzigen Pfades, ohne dabei Verzweigungen – sogenannte Branches – aufzuweisen. Auf diesem Hauptentwicklungspfad – im Englischen auch Trunk genannt – werden dann sequenziell Releases erstellt, welche immer wieder neue Funktionen (zu Neudeutsch auch Features) enthalten. So entwickelt sich die Standard-Lösung im Verlaufe der Zeit stets weiter. Und so bleibt auch jederzeit sichergestellt, dass ein früherer Release der Software problemlos auf einen neueren Release aktualisiert werden kann. Man spricht dabei von der Release-Fähigkeit der Software, einem ganz kritischen Punkt bei der Konfigurierbarkeit, auf die wir unten dann kommen.

Die Entwicklungsstrategie ist entscheidend

Verschiedene Kunden bzw. Anwender der Software können also dieselbe Standard-Software aber mit unterschiedlichem Release-Stand haben. Bei einer Standard-Software gibt es zu keinem Zeitpunkt Parallelversionen, welche aus einem gemeinsamen früheren Release entsprungen sind (eben Branches) und welche unterschiedliche Kundenbedürfnisse abdecken. Um genau zu sein: Solche Parallelversionen gibt es "nach aussen hin", also zum Markt hin nicht. Intern kann die Entwicklung durchaus verschiedene Branches haben, damit verschiedene Teams parallel an verschiedenen Teilen der Software arbeiten können. Diese Entwicklungs-Branches werden dann zu gegebener Zeit einfach wieder zu einem Markt-Release zusammengeführt. Merging nennt sich das.

Die Entwicklungsstrategie des Lieferanten sollte es nun sein (zumindest nach unserem Dafürhalten), möglichst alle unterschiedlichen Bedürfnisse der verschiedenen Kunden unter einen Hut zu bringen, indem generische Lösungen gefunden werden. Diese breit einsetzbaren Lösungen können dann kundenspezifisch konfiguriert werden, um trotzdem der spezifischen Situation des Kunden Rechnung zu tragen. Hier stossen wir nun zum ersten Mal auf den Begriff "konfigurierbar".

Bei einer solchen Entwicklungsstrategie müssen natürlich situativ auch Kompromisse gefunden werden, indem z.B. aus mehreren Lösungsvarianten für ein und dasselbe Kundenbedürfnis bewusst nur eine implementiert wird, welche dann entweder gar nicht oder nur eingeschränkt konfiguriert werden kann. Hier muss der Software-Lieferant halt auch mal in Kauf nehmen, es nicht allen Kunden recht machen zu können, um dafür konsequent seine Strategie zu verfolgen. Die Vorteile kommen dann nämlich allen Kunden wieder zu Gute. Wir kommen zum Schluss dieses Artikels nochmals darauf zurück.

Die Konfigurierbarkeit liegt in der Datenbank, nicht im Quellcode

Nun also zum zentralen Begriff dieses Textes: Konfigurierbarkeit. Andere sprechen hier auch von Parametrisierung oder ähnlichen Begriffen. Die Konfigurierbarkeit einer Standard-Lösung kann folgendermassen erklärt werden.

Eine typische Software-Installation besteht im Falle einer Geschäftsanwendung mit üblicher 3-Tier-Architektur etwas vereinfacht ausgedrückt aus einem Applikationsserver (Middle Tier) und einem Datenbankserver (Lower Tier). Der Anwender greift über einen Client (Upper Tier, bei einer Web-Applikation ist dies der Browser) auf den Applikationsserver zu. Pro Installation können nun Einstellungen (Konfigurationswerte) in der Datenbank des Systems abgelegt werden, welche das Verhalten des Systems steuern. Der Applikationsserver basiert aber auf einem bestimmten Release. Trotzdem stellen die Anwender unterschiedliche Funktionalitäten bzw. Verhaltensweisen des Systems fest, je nachdem wie das System konfiguriert ist.

Der entscheidende Punkt ist folgender: Die erwähnten Konfigurationswerte liegen in der Datenbank (allenfalls in Konfigurationsdateien im Applikationsserver), aber keinesfalls als Teil des Quellcodes im Applikationsserver. Echte Konfiguration hat also nichts mit einer kundenspezifischen Weiterentwicklung oder Adaption des Quellcodes zu tun. Denn dadurch würden nämlich unliebsame Verzweigungen entstehen, welche dann die Release-Fähigkeit gefährden oder gar verunmöglichen. Genau dies macht dann die Weiterentwicklung für den Kunden teuer, da solche Weiterentwicklungen für jeden Kunden separat gemacht werden müssen und der einzelne Kunde nicht von einer übergreifenden Weiterentwicklung für alle Kunden profitieren kann.

Konfigurierbarkeit heisst somit insbesondere nicht, dass Anpassungen durch Programmierung des Quellcodes erfolgen. Die Anpassung des Quellcodes erfolgt immer und ausschliesslich durch generische Weiterentwicklung der Grundfunktionalitäten der Standard-Software und führt zu einem neuen Release. Bestehende Konfigurationen können dabei im neuen Release einfach übernommen werden. Dies ist die Release-Fähigkeit von konfigurierbaren bzw. bereits konfigurierten Standard-Software-Systemen.

Woran erkennt man konfiguierbare Software?

Diese Frage ist nicht so leicht zu beantworten aus der Aussensicht, sprich aus der Sicht des Kunden, der eine solche Software evaluieren und kaufen will. Aus der Innensicht des Entwicklers ist dies natürlich einfach. Aber dem Kunden wird im Verkaufsprozess u.U. eine eigentlich überhaupt nicht konfigurierbare Software (im oben definierten Sinne) als "konfigurierbar" präsentiert, die diesen Stempel gar nicht verdient.

Eine solche Lösung mag durchaus zurecht als Standard-Software bezeichnet werden, weil sie entlang eines einzigen Release-Pfades weiterentwickelt wird. Aber sie wurde halt nicht von Beginn weg mit einer Entwicklungsstrategie gebaut, die Funktionalitäten generisch umsetzt und durch Konfiguration adaptierbar macht. Die "Konfigurierbarkeit" solcher System wird dann effektiv durch Weiterentwicklung umgesetzt. Dem Kunden wird das dann natürlich nicht so verkauft.

Einige einfache Merkmale von (echt) konfigurierbarer Software sind die Folgenden:

• Eine kundenspezifische Konfiguration ist kostengünstig, weil sie nur wenig Umsetzungsaufwand für den Lieferanten bedeutet.
• Die Konfiguration ist zeitlich schnell umsetzbar (mit derselben Begründung).
• Das System bleibt jederzeit release-fähig, d.h., Upgrades auf zukünftige Releases kosten nichts, weder Geld noch Aufwand.

Im Falle von PQFORCE beispielsweise bedeutet eine Kundenkonfiguration (des Gesamtsystems wohlgemerkt) einen ungefähren Aufwand von ½ bis 2 Tagen, je nach konkreten Wünschen und Detaillierungsumfang. Und wenn wir einen neuen Release anbieten, kann dieser jedem Kunden ohne Aufwand einfach aufgespielt werden.

[poll/110626]

Die Vorteile von konfigurierbarer Standard-Software aus der Cloud

Zum Abschluss möchten wir nochmals die wichtigsten Vorteile von konfigurierbarer Standard-Software aus der Cloud im Vergleich zu Individual-Software aufführen. Eine Software wie PQFORCE...

• ...ist in der Beschaffung deutlich günstiger. Und wir sprechen hier nicht von Prozenten, sondern von Faktoren. Ganz einfach deshalb, weil kein teueres Entwicklungsprojekt finanziert werden muss. Und die Konfigurierbarkeit ermöglicht sogar eine kundenspezifische Anpassung zu äusserst geringen Kosten – für alle jene Kunden, die sich nicht mit der Out-of-the-Box Lösung abfinden möchten.
• ...ist nach dem Kauf in enorm kurzer Zeit einsatzbereit. Das Aufsetzen eines PQFORCE-Mandanten dauert einige Minuten (sic!), und der Pilotbetrieb kann somit unmittelbar starten. Hier ist eher die Bereitschaft der kundenseitigen Organisation der Bremsfaktor.
• ...ermöglicht es, Skaleneffekte zu nutzen. Die Weiterentwicklung wird nämlich von einem ganzen Kundenportfolio getrieben (Crowdsourcing) und finanziert (Crowdfunding).
• ...bietet in kurzen Zyklen von einigen Wochen regelmässige Neuerungen (Feature Releases), welche von Kunden initiiert und unmittelbar genutzt werden können, sobald sie verfügbar sind (DevOps Prinzip).

Kein Wunder also, dass in der heutigen Zeit der Trend ganz eindeutig in Richtung cloud-basierter Standard-Software geht. Wenn diese dann noch richtig gut konfigurierbar ist, dann haben Sie als Kunde alle Vorteile auf Ihrer Seite.