Software-Hersteller für Enterprise Resource Planning-Tools (ERP) stehen vor der Herausforderung, webbasierte Anwendungen nach dem neuesten Stand der Technik zu entwickeln. Der folgende Beitrag beschreibt den Weg zur neuen ERP-Software über ein eigenes Entwicklungswerkzeug.
 
Ende der 90er Jahre hatten die Bedeutung und die Geschwindigkeit des Internets so stark zugenommen, dass eine Veränderung in der Architektur betriebswirtschaftlicher Software-Lösungen absehbar war. Dennoch sind Systeme, die eine mehrschichtige, internetfähige Architektur aufweisen, noch immer die Ausnahme. Dies mag an den hohen Anforderungen liegen: Die Produkte müssen internetfähig sein, plattformunabhängig, mehrsprachig, beliebig skalierbar, datenbankunabhängig. Sie sollten mit Smart-Clients laufen und auf Standards aufbauen. Ist das neue System eine Standardsoftware, sind zusätzlich Anforderungen an die Anpassungs- und Releasefähigkeit gestellt. Auch kleinere Unternehmen kommen oft nicht mit dem Standard aus und benötigen Erweiterungen. Die Software bläht sich auf oder bildet Spezialversionen aus, die separat gepflegt werden müssen. So bindet sie immer mehr Ressourcen für die Wartung und Pflege, was die Effizienz sinken und die Kosten steigen lässt. Dieser Herausforderung kann man mit einer kleinen Armee von Entwicklern und Beratern begegnen oder man sucht einen technischen Weg. Eine Möglichkeit besteht darin, den Entwicklungs- und den Customizingprozess durch ein entsprechendes Werkzeug zu unterstützen. Was bei der Spieleentwicklung längst üblich ist – niemand wird eine eigene Grafik-Engine schreiben, um anschließend seine Spielidee zu realisieren –, lässt sich auf den Entwicklungsprozess von Standardsoftware übertragen.  
 
Über die Entwicklungsumgebung zur ERP-Software
 
Für die Entwicklung der neuen ERP-Software von Nissen & Velten war im Jahr 2001 kein Werkzeug in Sicht, das die gestellten Anforderungen erfüllte. Also entwickelte der Software-Hersteller selbst eines. Die Verwendung eines Frameworks ist für Hersteller von Standard-Software sicherlich nichts Ungewöhnliches. Neu an dem gewählten Ansatz ist allerdings, dass das Tool nicht nur den Entwickler unterstützen soll, sondern das Produkt über den gesamten Lebenszyklus.
 
Um ausufernde Strukturen zu vermeiden und gleichzeitig mehr Flexibilität für individuelle Wünsche zu gewinnen, muss eine Trennung zwischen Hersteller- und Kunden-Logik erfolgen. Zusätzlich kann Länder-, Branchen- oder Konzernlogik zur Abbildung der Geschäftsprozesse notwendig sein. Bei Standardsoftware werden zudem auch Integrationspartner und Kunden ein Interesse am Erstellen von Ebenen haben, die den Standard ändern und erweitern.
 
Das Problem kann gelöst werden, indem nicht wie üblich auf Quellcodedateien basierend entwickelt wird, sondern in einer Datenbank, einem Repository. Alle Klassen werden dort in ihrer Struktur erfasst und als Datensätze gespeichert. In diesen Datensätzen wird festgehalten, zu welcher Logik-Ebene die Klasse gehört und welche Version diese hat. Die Entwicklungssoftware Framework Studio nennt die Logik-Ebenen Packages. Diese Packages erben voneinander, wobei die Vererbungshierarchie zwischen den Packages variabel ist. Bei der Generierung des C# - Quellcodes wird die Hierarchie der Packages berücksichtigt und die Klasse entsprechend erstellt.