Ein perfektes Team: abas-Datenbank und abas-Business-Software

Karlsruhe, 26.05.2010 - Von Beginn an wurde die abas-Datenbank auf die Bedürfnisse der Software zugeschnitten. Die gewachsenen Strukturen bringen dem Kunden heute drei entscheidende Vorteile: Die abas-Datenbank wird von der ABAS Software AG für den Kunden mitgepflegt, Datenbank und Software haben stets den gleichen Versionsstand und die abas-Business-Software ist auch nach kundenspezifischen Anpassungen immer upgradefähig. Die Zukunft bei ABAS heißt Parallelisierung. Pragmatismus "Wenn heute eine Datenbank auf den Markt käme, die unsere Anforderungen erfüllt oder die die zu bewältigenden Aufgaben besser abbilden könnte als unsere eigene, dann würden wir sie nehmen, da sind wir pragmatisch", so die Aussage aus der Entwicklung der ABAS Software AG. Die Datenbank ist ein Instrument, das der ERP-Software dient und nicht umgekehrt. Ein Blick in die Vergangenheit zeigt, dass es Momente gab, in denen dieser Schritt erwogen wurde. Der Rückblick verdeutlicht auch, dass es gut ist, eigenen Prinzipien zu vertrauen und nicht vorschnell neuen Lösungen Vorrang zu geben. Und er zeigt, dass manchmal einige Entwicklungen einfach "State of the Moment" sind. Solides Fundament 1982 galt es, für die vom Unternehmensberater Wolfgang Dannemann angestrebte Unternehmenssoftware, die heutige abas-Business-Software, eine Datenbank zu finden. Anfang der achtziger Jahre waren viele Datenbankansätze noch jung, externe Datenbanken kosteten viel Geld und waren für den Einsatz auf Großrechnern konzipiert. Die Entscheidung für oder gegen eine bestimmte Datenbank wollte wohl überlegt sein. Hätte man zu diesem Zeitpunkt auf das falsche Pferd gesetzt, hätte das den finanziellen Untergang des jungen Unternehmens bedeuten können. Ein Schicksal, das manchen Mitbewerber in der Branche ereilt hat. Die beiden Entwickler der ersten Stunde, Erich Sartori und Reinhard Harms, orientierten sich bei ihrer Entscheidung an den Bedürfnissen ihrer Kunden und das war der Mittelstand. Das bedeutete: die gesuchte Lösung durfte das eigene Produkt nicht zu sehr verteuern, die Datenbank sollte für den Einsatz in mittelständischen Unternehmen ausgelegt sein und entsprechend nicht zu viele Ressourcen benötigen. Mehrplatzfähige Rechner, also MPM-Systeme, waren die Zielplattform. Vor diesem Hintergrund wurde entschieden, eine eigene Datenbank zu entwickeln. Die beiden jungen Informatiker reizte die Herausforderung an einem realen und anspruchsvollen Werk ihr Informatikerkönnen unter Beweis zu stellen, das war ihnen lieber, "als irgendwelche Funktionen im Rechnungswesen zu programmieren", erinnert sich Sartori. Sie gingen mit Elan an die Arbeit. Start war Januar 1982. Ein halbes Jahr später im Juli 1982 war die in Basic programmierte Datenbank fertig. Diese Vorversion wurde 1983 in die Programmiersprache "C" übertragen und damit für Unix-Systeme verfügbar gemacht. Damit konnte die nächsten zehn Jahre gearbeitet werden, kleine Korrekturen und Verbesserungen inbegriffen. Damals sprach noch keiner von relationalen oder objektorientierten Datenbanken. Anfang der achtziger Jahre begannen sich die relationalen Datenbanken gerade auf dem Markt durchzusetzen. Was die beiden entwickelten, besaß viele Grundelemente, die gegenwärtig der objektorientierten Datenbank zugeordnet werden. Ein Fundament, das sich heute, viele Jahre später, als vorteilhaft erweist und das nach wie vor eine stabile Basis für die Umsetzung moderner Anforderungen ist. Die geschützte Datenbank - Garant der Upgradefähigkeit Die in herkömmlichen ERP-Systemen übliche Trennung zwischen Anwendungs- und Datenbankschicht wurde durch eine konsequente Verflechtung dieser beiden Ebenen ersetzt. Das bedeutet: Lesende und schreibende Zugriffe auf die Daten erfolgen stets über die für die jeweiligen Objekte (Verkauf, Kunde, Artikel usw.) definierten Objektmethoden. Diese Entscheidung wurde sehr früh getroffen und konsequent durchgezogen. Der Datensatz zusammen mit den Methoden, die er kennt, bilden das abas-Objekt. Grafik 1: http://www.abas.de/de/aktuelles/30jahreabas/datenbank.htm Die abas-Objektmethode sorgt für eine konsistente Datenbank. Noch deutlicher wird dieser Vorteil, wenn man das gegenläufige Konzept der Trennung dieser beiden Schichten, also der Anwendungs- und Datenbankschicht, betrachtet, wie es in relationalen Datenbanken umgesetzt ist. Vereinfacht kann man sich dieses Zusammenspiel mit Hilfe von Excel vorstellen. Die Exceldatei ist die Datenbank. Hier existieren zahlreiche Tabellen, in denen die Daten abgelegt sind, beispielsweise zwei mit Kunden und Aufträgen. Auf diese Tabellen greift ein ERP-Programm zu, um einen Auftrag zu erfassen. Im ERP-System wurden für die Datenerfassung Regeln festgelegt, beispielsweise, dass ein Auftrag nur in Verbindung mit einem Kunden angelegt werden kann. Damit wird verhindert, dass inkonsistente Daten entstehen. Auf dieser Ebene wird die Einhaltung der Regeln überprüft. Entschließt sich nun ein Anwender, einfach direkt in die Excel-Tabelle zu gehen, also in die Datenbank, und dort den Auftrag ohne Kunden anzulegen, kann das auf dieser Ebene nicht verhindert werden. Die Geschäftsregeln der oberen Ebene wurden außer Kraft gesetzt. Durch die konsequente objektorientierte Kapselung ist ein solches Vorgehen bei der abas-Business-Software nicht möglich. Im Gesamtaufbau der abas-Business-Software wurde generell dafür gesorgt, dass Softwarekern und Datenbank nur von der abas-Entwicklung in Karlsruhe verändert werden können. Dieses Prinzip ermöglicht den abas-Kunden der ersten Stunden bis heute Upgrades vorzunehmen, ohne auch nur einmal die Daten migrieren zu müssen. Eine weitere Besonderheit der abas-Datenbank: die Clients entlasten den Datenbankprozess, indem sie die Datensätze auspacken. Das macht kein anderes ERP-System. Dadurch entlastet abas-ERP von Anfang an den Datenbankprozess. Herkömmliche Standarddatenbanken führen diese Aktion im Datenbankprozess aus. Anfang der 90er Jahre - Überlegung Standarddatenbank einzusetzen Mitte der 90er prüften die abas-Entwickler den Einsatz anderer Datenbanklösungen. Man war beeinflusst durch die allgemeine Diskussion über die Vorteile von Standarddatenbanken, und die Überlegung stand im Raum, ob es nicht geschickter sei, die Weiterentwicklung anderen zu überlassen und auf deren Ergebnissen aufzusetzen. Geprüft wurde 1993 zunächst der Einsatz von Informix von der gleichnamigen Firma. Die Datenbankobjekte waren jedoch anders geschrieben und die notwendige Normierung wurde als zu aufwändig eingestuft. Auch die Möglichkeit der Kapselung von Anwendung und Datenbank konnte den abas-Ansprüchen nicht standhalten. Drei Jahre später wurde FastObjects t7, damals ein Produkt der Firma POET, geprüft. Der Code für die Anbindung wäre allerdings ähnlich umfangreich ausgefallen wie für den eigenen Datenbankkern, und in zahlreichen Bereichen wäre ein doppelter Pflegeaufwand entstanden. Keine Datenbank erfüllte Mitte der 90er die Anforderungen der ABAS Software AG. Man beschloss, der eigenen Lösung treu zu bleiben und diese weiter zu verbessern. Aus der heutigen Sicht war die Entscheidung ein Glücksgriff, denn weder Informix noch Poet haben als Firmen überlebt. Weiterentwicklung der eigenen Datenbank Die eigene Datenbank wurde parallel zur Prüfung der Standarddatenbanklösung intensiv weiterentwickelt. Aufgrund der schnellen Entwicklung von abas-ERP wurden immer mehr Funktionen abgebildet und entsprechend mehr Daten gespeichert. Auch die Ansprüche der Kunden an die zu speichernden Daten wurden vielschichtiger. Ab 1994 stellte ABAS zunächst eine feste Anzahl von "Reserve"-Feldern zur Verfügung, um Kundenwünschen gerecht zu werden. Objekten, wie beispielsweise Artikel, Ver- oder Einkauf, konnten so kundenindividuelle Attribute hinzugefügt werden. Ab 1996 war es dann möglich, die Objekte mit beliebig vielen Feldern zu ergänzen, ohne dabei die Upgradefähigkeit zu verlieren. Die Transaktionssicherheit war zu diesem Zeitpunkt zu einer großen Aufgabe herangewachsen. ABAS entwickelte vielfältige Werkzeuge, die Datenbankreparaturen nach Inkonsistenzen automatisch vornahmen. Die Werkzeuge wurden zwar später nach der Einführung von Transaktionen und Rollbacks (s.u.) in ihrer eigentlichen Funktion überflüssig, werden aber heute in der hauseigenen Qualitätssicherung weiterverwendet für die Überprüfung und Sicherstellung der Datenbankkonsistenz bei der Weiterentwickelung der Anwendungslogik. ABAS dürfte zur Zeit der einzige mittelständische ERP-Anbieter sein, der über eine solche Art der Qualitätssicherung verfügt. Ins neue Jahrtausend mit der leistungsstarken Logdatenbank Die Einführung der Logdatenbank war ein Meilenstein in der abas-Datenbankgeschichte. Seit Version 2003 ist die abas-Business-Software mit ihr ausgerüstet. Ihre Technik unterscheidet sich von herkömmlichen Datenbankkonzepten grundlegend. Wesentlichstes Merkmal: Es werden keine bestehenden Datenobjekte mehr geändert, sondern nur neue Datenobjekte erzeugt. Das bisherige Datenbankobjekt wird als ungültig gekennzeichnet und mit dem "garbage collector" aus der Datenbank entfernt. Dieses Verfahren hat gegenüber den herkömmlichen Strategien zahlreiche Vorteile: ...Es ermöglicht, eine Schattendatenbank zu erzeugen. Datensicherungen können im laufenden Betrieb erfolgen, ein 24-Stunden-Betrieb an 7 Tagen die Woche ist gewährleistet, die Netzwerkbelastung wird reduziert und Daten können außerhalb der Firewall zur Verfügung gestellt werden. ...Die Schreibperformance ist wesentlich höher aufgrund der ausschließlich sequenziellen Schreibzugriffe. Eine weitere wesentliche Entwicklung in der Logdatenbank war die Einführung von Transaktionen, die dann das Rollback ermöglichen. Ein Rollback ist das Zurücksetzen aller Verarbeitungsschritte einer Transaktion. Dies geschieht typischerweise nach dem Auftreten eines Fehlers. Die Datenbank wird dann vollständig auf den Zustand vor dem Beginn der Transaktion zurückgesetzt. Mit der neuen Logdatenbank wurde das Fundament gelegt, um künftig, voraussichtlich ab Herbst 2010, die Parallelisierung anzubieten, mit der ABAS in der Lage ist, die Kapazität von mehrkernigen Rechnern für seine Datenbankleistung voll zu nutzen. Die Zukunft: abas-Logdatenbank ermöglicht Parallelisierung Zurzeit findet ein Umbruch in der Rechnerarchitektur statt. Seit drei Jahren sind keine schnelleren Prozessoren mehr auf dem Markt, sondern nur mehrkernige, also mehrere Prozessoren auf einem Chip. Das Wachstum in der Rechnerleistung ist entsprechend nur noch durch eine wachsende Anzahl parallel arbeitender Prozessoren möglich. Datenbanken müssen sich dieser Entwicklung anpassen, sonst werden sie zum Flaschenhals. Hier setzt die Parallelisierung der ABAS Software AG an. Durch die Parallelisierung nimmt die Skalierbarkeit zu, das bedeutet mit wachsender Prozessorzahl wächst die Leistung des Systems. Zurzeit läuft auf einem Prozessor der Datenbankprozess, er ist dafür verantwortlich die Daten von der Festplatte zu holen und wieder abzulegen. Die Anwendungsprozesse "reden" mit ihm, um Daten beispielsweise für die Auftragserfassung, Disposition oder Stammdatenpflege abzurufen und zu speichern. Grafik 2: http://www.abas.de/de/aktuelles/30jahreabas/datenbank.htm Kommunikation der Anwendungsprozesse und Datenbank ohne Parallelisierung Die abas-Business-Software skaliert schon jetzt aufgrund der Auspackarbeit der Clients sehr gut. Zur Zeit wird der gesamte Lese- und Schreibverkehr zur Festplatte vom Datenbankprozess erledigt. Das bedeutet: Bei einer hohen Zahl von Anwendungsprozessen mit einer sehr hohen Aktivität, kann der Datenbankprozess zu einem Flaschenhals werden, da er nur auf einem Prozessor laufen kann. Dieser Effekt wurde bei ABAS unter entsprechenden Testbedingungen überprüft. In der Praxis ist er noch nicht aufgetreten. Durch die Parallelisierung wird auch noch der Lese- und Schreibverkehr von den Anwenderprozessen erledigt, so dass dieser potenzielle Flaschenhals entfällt. Der Datenbankprozess verwaltet nur noch die Datensatzsperren. Ab Herbst 2010 können abas-Kunden mit einem hohen Bedarf an Datenbankzugriffen auf die Vorteile der Parallelisierung zurückgreifen. Jeder Anwendungsprozess liest und schreibt die Daten von der Datenbankfestplatte ohne Kommunikation mit dem Datenbankprozess. Der Flaschenhals entfällt. Geordnet wird der Zugriff der zahlreichen Prozesse über den "Global Lock Manager". Er stellt sicher, dass nacheinander ans Ende der Logdatenbank geschrieben wird. Grafik 3: http://www.abas.de/de/aktuelles/30jahreabas/datenbank.htm Kommunikation der Anwendungsprozesse und Datenbank mit Parallelisierung Für jeden weiteren Client-Rechner übernimmt dessen Prozessor auch Datenbank-Server-Aufgaben und hilft damit, die gestiegene Last wieder abzubauen. Eine wachsende Anzahl von Nutzern kann also mit einer zunehmenden Anzahl von Prozessoren weiterhin gleich schnell arbeiten. Mit Hilfe der Parallelisierung kann die abas-Business-Software in Bezug auf ihre Leistung die momentane Entwicklung der Hardware in Richtung massiv parallele Hardwarearchitektur voll nutzen. Die Parallelisierung steht erst am Anfang ihrer Entwicklung und wird ein prägendes Thema der EDV in den nächsten Jahrzehnten sein. FAZIT: Die abas-Datenbank hat viele Vorteile Vor rund fünfzehn Jahren war die eigene Datenbank manchmal für Großunternehmen ein K.O.-Kriterium. Heute spielt die Frage nach einer Standarddatenbank in Verkaufsgesprächen keine entscheidende Rolle mehr. Dem Kunden ist in erster Linie Dienstleistung wichtig. Die abas-Datenbank ist auf die Bedürfnisse der abas-Business-Software optimiert und wird vom Karlsruher Softwarehaus mitgepflegt. Für den Kunden bringt das drei entscheidende Vorteile: Erstens, er braucht keinen Administrator, der die abas-Datenbank pflegt. Zweitens die abas-Datenbank und die abas-Business-Software haben stets den gleichen Versionstand. Der Anwender kann sich also darauf verlassen, dass neue Funktionen zuverlässig mit der Datenbank korrespondieren. Und drittens, die abas-Business-Software ist auch nach kundenspezifischen Anpassungen immer upgradefähig, da der objektorientierte Ansatz der Software dafür sorgt, dass bei Anpassungen keine Regeln verletzt werden. Welcher Anbieter kann das noch? Das Austauschen der abas-Datenbank ist nach wie vor kein Tabuthema im Karlsruher Softwarehaus. Voraussetzung einen solchen Schritt in Erwägung zu ziehen, wäre, dass ein besseres und zukunftssicheres Produkt für die Anforderungen der abas-Business-Software auf dem Markt zur Verfügung steht. Wie wahrscheinlich ist das? Welcher der abas-Kunden möchte die genannten Vorteile missen? Die abas-Datenbank ist schnell, gut gerüstet für die Zukunft und benötigt keinen Administrator, was will man mehr? ABAS ist in der Lage, die zukunftsweisende Parallelisierung auf einem für den Mittelstand zugeschnittenen Preisniveau anzubieten. Wer kann diese Vorteile zur Zeit toppen? (te) ABAS Software AG Christoph Harzer Südendstr. 42 76135 Karlsruhe presse@abas.de +49 721/9 67 23-0 http://www.abas.de/de/presse/presse.htm