In Anlehnung an unsere Beobachtungen während der Implementierung zahlreicher Massendatensysteme haben wir ein eigenes Modell für den Aufbau solcher Lösungen entwickelt. Es basiert auf einer – von uns geschaffenen – Programmierplattform, die es uns ermöglicht, äußerst effiziente und skalierbare Systeme für besonders anspruchsvolle Kunden zu erstellen.
Die Grundlage unserer Lösungen ist eine einheitliche Programmierplattform (mit anderen Worten eine für viele Installationen identische Plattform), auf der Microservices bereitgestellt werden (vor der Entstehung des Konzepts der Microservices Module oder Konverter genannt), die auf die Bedürfnisse unseres Kunden zugeschnitten sind (und daher je nach Installation unterschiedlich sind). Dies bedeutet einerseits, dass wir unsere Systeme nicht von Grund auf bauen müssen, da wir eine stabile, gründlich getestete und für viele Implementierungen geeignete Plattform benutzen, und andererseits, dass wir uns dank dieser Funktionsweise maximal an die Bedürfnisse des Kunden anpassen und im Hinblick auf seine Erwartungen präzise und optimierte Lösungen entwickeln können.
Die von uns entwickelte Atom-Plattform ist unser ganzer Stolz. Sie ist auf Leistung und Skalierbarkeit ausgelegt, damit sie als Fundament für ausgeklügelte Systeme, insbesondere Massendatensysteme, dienen kann.
Es reicht wohl zu sagen, dass die Atom-Plattform in der Regel Zehntausende von Netztransaktionen in einer Sekunde verarbeiten kann, auch mit ganz gewöhnlicher Hardware. Mit entsprechend konzipierten Datenstrukturen und für den Netzbetrieb geeigneter Hardware kann Atom sogar Hunderttausende, wenn nicht Millionen Transaktionen pro Sekunde verarbeiten.
MEHR ÜBER DIE ATOM-PLATTFORM:
URSPRÜNGE DER ATOM-PLATTFORM
Für die Implementierung von IT-Systemen gibt es viele konkurrenzfähige Methoden. Leider sind die meisten dieser Methoden für die Massendatensysteme, mit denen wir uns beschäftigen, völlig nutzlos. Bei bestimmten Implementierungen können sich ihre Unzulänglichkeiten auf besonders empfindliche Weise bemerkbar machen. Die Regel ist einfach – dort, wo maximale Leistung und Skalierbarkeit gefragt sind, macht die Anwendung gewöhnlicher Lösungen keinen Sinn.
Während der langjährigen Geschichte unseres Unternehmens haben wir auch verschiedene Modelle für die Entwicklung von Massendatensystem in Betracht gezogen:
| Entwicklungsmodell | Unsere Beobachtungen |
| Entwicklung einer fertigen, für alle Kunden geeigneten Anwendung „von der Stange“, ohne Funktionalitätseinschränkungen | Es stellte sich heraus, dass die Erstellung einer fertigen Anwendung dieser Art unmöglich ist. Für einen Teil unserer Kunden wäre sie zu komplex – und für den anderen Teil zu banal. Aufgrund der unterschiedlichen Anforderungen und Erwartungen war es vollkommen unmöglich, einen gemeinsamen Nenner für alle Kunden zu finden. Darüber hinaus wäre eine solche Anwendung kein Massendatensystem – sie wäre nicht in der Lage, beliebige Datenmengen optimal zu verarbeiten. Auch wäre die Konfiguration einer solchen Anwendung unter Umständen ausgesprochen zeitaufwändig. Und wir wollten ein recht verbreitetes Phänomen vermeiden, dass nämlich die Konfiguration bestimmter fertiger Systeme ebenso lange dauert wie die Entwicklung eines Systems von Grund auf. |
| Entwicklung einer fertigen Anwendung „von der Stange“ – aber mit Funktionalitätseinschränkung, sodass die Grunderwartungen der Kunden erfüllt werden können | Auch diese Lösung macht wenig Sinn. Schließlich müssen zur Optimierung von Massendatensystemen Datenstrukturen aufgebaut werden. Diese können jedes Mal anders ausfallen. Wie kann man also ohne Datenstrukturen ein System aufbauen, auch wenn es nur ein banales „Kastensystem“ sein soll? Kann man nicht. |
| Entwicklung von kundenspezifischen Systemen | Dies ist der Ansatz, den wir bevorzugen, und seit 1995 implementieren wir unsere Systeme auf genau diese Weise. Diese Methode ermöglicht die Entwicklung sehr leistungsfähiger Lösungen in Abstimmung auf konkrete Bedürfnisse. Sie erfüllt also die Anforderungen, die wir an Massendatensysteme stellen. Darüber hinaus zahlt der Kunde nur für Funktionen, die er auch wirklich nutzt. Leider ist hier jede Implementierung einmalig. Fehler, die in einem System gefunden werden, sind ganz anders als Fehler in einem anderen System. Das bedeutet, dass jegliche Korrekturen (und auch Upgrades) getrennt bearbeitet werden müssen. Dies wiederum bedeutet höhere Kosten für Wartung und Anwendungsunterstützung im weiten Sinne. |
Vergleich der Methoden der Systementwicklung
In der folgenden Tabelle vergleichen wir die Methoden der Anwendungsentwicklung
| Anwendung von der Stange mit grundlegender Funktionalität | Erweiterte Anwendung von der Stange mit voller Funktionalität | Kundenspezifisch entwickelte und implementierte Anwendung | Kundenspezifische Anwendung mit Nutzung einer Programmierplattform | |
| Leistung | “-” | “-” umfangreiche konfigurierbare Umgebungen erfordern beachtliche Ressourcen, um die Konfigurierbarkeit zu gewährleisten – auf Kosten der Leistung | “+” perfekt – das System wird unter Berücksichtigung aller Leistungserwartungen des Kunden entwickelt | “+” die Programmierplattform gewährleistet maximale Skalierbarkeit und Leistung (Netz/Cloud). Sowohl die Datenstrukturen als auch die Module selbst können beliebig optimiert werden |
| Funktionalität | “+/-” für grundlegende Aufgaben sehr gut, aber für komplexere Implementierungen nicht ausreichend | “+” manchmal sogar zu viel | “+” ideal auf die Kundenbedürfnisse abgestimmt | “+” ideal auf die Kundenbedürfnisse abgestimmt |
| Einfachheit der Implementierung | ”+” | “+” in komplexen, konfigurierbaren Systemen bildet die Konfiguration ein eigenes Wissensgebiet und kann (muss aber nicht) genauso kompliziert sein, wie die Entwicklung eines Systems von Grund auf; der Kunde kann auch unter Umständen gezwungen sein, sich bei bestimmten Lösungen an das System anzupassen | “-” leider muss die gesamte Anwendung implementiert werden – mit allen, auch den standardmäßigen Mechanismen, andererseits ist die Anwendung auf die Firma, in der sie betrieben werden soll, abgestimmt – sie passt besser zu ihr und lässt sich leichter implementieren (z. B. muss in den Schulungen nicht auf den neuen Systemansatz, sondern nur auf die Regeln für die Bedienung des Systems eingegangen werden) | “+” die Plattformen, die wir benutzen, sind fertig. Einschließlich einer Standard-Benutzeroberfläche. Es muss nur noch der Überbau entwickelt werden |
| Dauer der Implementierung | “+” konkurrenzlos | “-” es kommt vor, dass die Konfigurierung einer ausgebauten, konfigurierbaren Anwendung wegen der Komplexität genauso viel Zeit in Anspruch nimmt, wie die Entwicklung eines Systems von Grund auf | ”-” | “+” deutlich kürzer als bei der Entwicklung eines Systems von Grund auf, die Plattformen sind sofort verfügbar. Man kann sich auch leicht auf bereits vorhandene Konfigurationen stützen |
| Der Kunde zahlt für das, was er wirklich braucht | ”-” | “-” der Kunde zahlt pauschal für die Anwendung, das heißt, wenn er eine bestimmte Option nicht wünscht, zahlt er für sie im Standardpreis und während der Konfiguration zahlt er für ihre Löschung … | “+” einer der wesentlichen Vorteile | “+” zwar kauft der Kunde die ganze Plattform, aber er nutzt auch praktisch immer die ganze Plattform |
| Zugang zu Upgrades / Code-Sharing mit anderen Benutzern | ”+” | “-/+” (teilweise – hängt davon ab, wie sehr die Systemgrundlagen durch die Konfiguration verändert wurden) | ”-” | “+” im Rahmen der Plattform – voller Zugang, im Rahmen des Überbaus – ja, wenn der betreffende Überbau bei vielen Kunden installiert wurde |