Hallo Raketenwilli, ich glaube nicht, dass das eine Frage der Programmiersprache ist. Sinnvolle, performante und gut strukturierte Software kann ich mit C#, Java oder PHP gleichermaßen erstellen. Wenn's sein muss, auch mit Perl oder JavaScript auf einem node.js Gerät. Und mit jeder dieser Sprachen kann ich auch ein Knäuel unentwirrbares Spaghetti erschaffen. Die Qualität einer Software wird vor der Tastatur entschieden. Die Mandantentrennung in Form von getrennten DBs durchzuführen ist nicht falsch. Man speichert damit vielleicht ein paar Grunddaten doppelt - aber wenn es um Dinge wie Meldungstexte geht, kann man die auch in eine separate readonly DB auslagern, die von allen Mandanteninstanzen gemeinsam genutzt wird. Ich denke, Sven und sein Kunde liegen mit dem Verständnis einer Cloud-Lösung über Kreuz. Sven ist ein reiner Cloud-Anbieter, und der Kunde möchte die Cloud-Vorteile haben ohne die potenziellen Nachteile (Verfügbarkeit und Zuverlässigkeit des Anbieters) einzugehen. Und da gibt es nun mal Grenzen. Für den Fall einer Betriebsunterbrechung bei Sven muss er Vorkehrungen treffen und vor allem Servicelevel-Zusagen machen. Reißt er seinen Servicelevel, wird die Nummer teuer, und deswegen denke ich mal, dass er da ziemlich fleißig gewesen ist. Für den Fall, dass Sven seinen Betrieb einstellt, muss es Vorkehrungen geben, die die Betriebsfortsetzung der Kunden garantieren. Für eine Einstellung gibt es diverse Gründe. Insolvenz ist einer. Dann gäbe es da noch einen dumm platzierten Baum, plötzliche Arbeitsunfähigkeit aus Gesundheitsgründen, akute Bleivergiftung weil ein Idiot Amok läuft während Sven einkauft, etc etc. Auch da muss Sven Vorkehrungen haben. Vorzugsweise in Form eines hinreichend großen und kompetenten Teams. Diese Vorkehrungen sollte der Kunde evaluiert haben und Vertrauen darin haben, andernfalls wäre es fahrlässig, das Cloud-ERP System bei Sven zu hosten. Ein reines Offline-Backup der Daten nützt jedenfalls gar nichts, das habt ihr ja herausgearbeitet. Eine Offline-Version der Software incl. Datenbank wäre sicher möglich. Unser Wiki gibt's ja auch als Offline-Paket. Aber es widerspricht der Cloud-Idee, es widerspricht Svens Betriebsinteresse und es würde voraussetzen, dass der Kunde die nötige Betriebsinfrastruktur selbst aufbaut. Dennoch muss es die Möglichkeit einer Übergabe von Software und Daten an den Kunden als Notfalllösung geben. Aber ausschließlich für den Fall, dass Sven den Betrieb nicht aufrecht erhalten kann und dadurch die Existenz des Kunden gefährdet ist. Dagegen dürfte Svens Interesse an seinen Betriebsgeheimnissen zurückstehen müssen. An Svens Stelle würde ich anbieten, in gewissen praktikablen Abständen einen Dump der Kunden-DB bereitzustellen. Und zwar als gut verschlüsseltes Komprimat. Den Schlüssel behält Sven. Für den Fall eines Datenverlustes er über das ZIP die Daten wiederherstellen. Für den Fall, dass er den Betrieb einstellen muss, kann er dem Kunden Schlüssel und Software aushändigen. Und ggf. auch noch den jüngsten Dump, sofern der Kunde ihn nicht schon hat. Wenn der Kunde UNBEDINGT eine jederzeit lesbare Version der Daten haben will, um darauf bspw. eigene Auswertungen machen zu können, hätte er keine Cloud-Lösung wählen dürfen. Das widerspricht sich einfach. Ich persönlich bin aber auch nicht überzeugt, dass die Struktur der ERP DB ein derartiges Betriebsgeheimnis sein kann. Solche DBs gibt es bei vielen Anbietern und die erforderliche DB-Struktur aus den relevanten Geschäftsvorfällen selbst herzuleiten ist für einen professionellen DB-Analysten kein Hexenwerk. Die Magie liegt in der Software, wie sie aus den Daten ihre Forecasts macht oder wie sie die Daten verknüpft. Sicherheitsgründe vorzubringen halte ich ebenfalls für verfehlt, denn Security By Obscurity ist nur ein Aufkleber über dem Etikett "Schlangenöl". _Rolf_ -- sumpsi - posui - obstruxi

Hallo Raketenwilli, ich glaube nicht, dass das eine Frage der Programmiersprache ist. Sinnvolle, performante und gut strukturierte Software kann ich mit C#, Java oder PHP gleichermaßen erstellen. Wenn's sein muss, auch mit Perl oder JavaScript auf einem node.js Gerät. Die Mandantentrennung in Form von getrennten DBs durchzuführen ist nicht falsch. Man speichert damit vielleicht ein paar Grunddaten doppelt - aber wenn es um Dinge wie Meldungstexte geht, kann man die auch in eine separate readonly DB auslagern, die von allen Mandanteninstanzen gemeinsam genutzt wird. Ich denke, Sven und sein Kunde liegen mit dem Verständnis einer Cloud-Lösung über Kreuz. Sven ist ein reiner Cloud-Anbieter, und der Kunde möchte die Cloud-Vorteile haben ohne die potenziellen Nachteile (Verfügbarkeit und Zuverlässigkeit des Anbieters) einzugehen. Und da gibt es nun mal Grenzen. Für den Fall einer Betriebsunterbrechung bei Sven muss er Vorkehrungen treffen und vor allem Servicelevel-Zusagen machen. Reißt er seinen Servicelevel, wird die Nummer teuer, und deswegen denke ich mal, dass er da ziemlich fleißig gewesen ist. Für den Fall, dass Sven seinen Betrieb einstellt, muss es Vorkehrungen geben, die die Betriebsfortsetzung der Kunden garantieren. Für eine Einstellung gibt es diverse Gründe. Insolvenz ist einer. Dann gäbe es da noch einen dumm platzierten Baum, plötzliche Arbeitsunfähigkeit aus Gesundheitsgründen, akute Bleivergiftung weil ein Idiot Amok läuft während Sven einkauft, etc etc. Auch da muss Sven Vorkehrungen haben. Vorzugsweise in Form eines hinreichend großen und kompetenten Teams. Diese Vorkehrungen sollte der Kunde evaluiert haben und Vertrauen darin haben, andernfalls wäre es fahrlässig, das Cloud-ERP System bei Sven zu hosten. Ein reines Offline-Backup der Daten nützt jedenfalls gar nichts, das habt ihr ja herausgearbeitet. Eine Offline-Version der Software incl. Datenbank wäre sicher möglich. Unser Wiki gibt's ja auch als Offline-Paket. Aber es widerspricht der Cloud-Idee, es widerspricht Svens Betriebsinteresse und es würde voraussetzen, dass der Kunde die nötige Betriebsinfrastruktur selbst aufbaut. Dennoch muss es die Möglichkeit einer Übergabe von Software und Daten an den Kunden als Notfalllösung geben. Aber ausschließlich für den Fall, dass Sven den Betrieb nicht aufrecht erhalten kann und dadurch die Existenz des Kunden gefährdet ist. Dagegen dürfte Svens Interesse an seinen Betriebsgeheimnissen zurückstehen müssen. An Svens Stelle würde ich anbieten, in gewissen praktikablen Abständen einen Dump der Kunden-DB bereitzustellen. Und zwar als gut verschlüsseltes Komprimat. Den Schlüssel behält Sven. Für den Fall eines Datenverlustes er über das ZIP die Daten wiederherstellen. Für den Fall, dass er den Betrieb einstellen muss, kann er dem Kunden Schlüssel und Software aushändigen. Und ggf. auch noch den jüngsten Dump, sofern der Kunde ihn nicht schon hat. Wenn der Kunde UNBEDINGT eine jederzeit lesbare Version der Daten haben will, um darauf bspw. eigene Auswertungen machen zu können, hätte er keine Cloud-Lösung wählen dürfen. Das widerspricht sich einfach. Ich persönlich bin aber auch nicht überzeugt, dass die Struktur der ERP DB ein derartiges Betriebsgeheimnis sein kann. Solche DBs gibt es bei vielen Anbietern und die erforderliche DB-Struktur aus den relevanten Geschäftsvorfällen selbst herzuleiten ist für einen professionellen DB-Analysten kein Hexenwerk. Die Magie liegt in der Software, wie sie aus den Daten ihre Forecasts macht oder wie sie die Daten verknüpft. Sicherheitsgründe vorzubringen halte ich ebenfalls für verfehlt, denn Security By Obscurity ist nur ein Aufkleber über dem Etikett "Schlangenöl". _Rolf_ -- sumpsi - posui - obstruxi