Hallo Sebastian,
Sebastian Gödecke
hat am 10. Juli 2015 um 07:44 geschrieben: [...] Also wenn ich es von den Modulen so sehe, dann etwas in der Richtung http://www.daarwin.de/sozialpsychiatrie.html?aid=3 So in dieser Richtung dachte ich.
Gut, du willst das Rundumsorglospaket. Verstehe ich. Ich fürchte das das gibt es nicht. Hier zwei Gedanken von mir dazu: 1. Monolithisch vs. Patchwork Wenn man Software evaluiert, hab man es (in aller Regel) immer mit zwei Ansätzen zu tun: Eine Software mit der man alles erschlägt oder mehrere Komponenten, die verschiedene Teilaufgaben abdecken. Natürlich gibt es auch Lösungen, die irgend wie in der Mitte liegen. Wenn ich mich für eine monolithisch Architektur entscheide, habe ich den Vorteil, dass das Bedienkonzept durchgängig das selbe ist. Dadurch die Einarbeitung der Benutzer schneller gehen und die Akzeptanz größer sein. Muss aber nicht. Die Software kann so scheiße sein, das die Mitarbeiter trotzdem das kotzen kriegen. Das Aufsetzen eines Monolithen und Warten kann schneller und leichter sein, als bei verdrahteten Komponenten. Der Nachteil von monolithisch Lösungen ist, das sie sich sehr schwer tun mit anderen Systemen zusammen zu arbeiten. Du das Fris-oder-stirb-Prinzip. Konkretes Beispiel. Die Software in deinem Link kann nur Kassenbücher für Klienten verwalten. Keine doppelte Buchführung. Wenn du das aber zwingend brauchst sitz du in der Scheiße. Du kannst nicht einfach ein Teil der Software austauschen. Selten ist es so, das main eine Software ein mal installiert und nie wieder anfässt. Bei monolithisch Lösungen hast du dann oft das Problem, das egal was du ändern willst, immer das gesamte System eine Downtime hat und nicht nur die Komponente die ein Update bekommt. Es ist die Natur der Dinge, das Software-Projekte einschlafen können. Wenn du dann eine monolithisch Lösungen hast, kannst du bei Null anfangen. Hast du hingegen ein modulares Konzept, braucht du "nur" die Komponente austauschen, die keine Updates mehr bekommt. Da die ganze Architektur darauf ausgelegt ist (oder sein sollte), über Standard Protokolle miteinander zu kommunizieren, sollte sich auch ein Ersatz finden lassen, der die gleiche API bedienen kann. 2. Implementierung und Betretung Ich habe zwar geschrieben, das Monolithen in aller Regel schneller installiert sind. "Schnell" ist aber immer relativ. Wenn nur begrenzt Ressourcen in Form von Zeit da ist, kann sich das auch sehr lange hinziehen, bis so ein System einsatzfähig ist. Hat man hingegen ein modulares System, kann man sich in Teil-Abschnitten vor robben. Am Ende jedes Abschnittes, steht dann ein funktionsfähiges Modul, das sofort ein Mehrwert generierten kann. Wenn man sichtbare Erfolge vorweisen kann, hat man es auch leichter, weitere Ressourcen in Form von Beugte und Personal zu bekommen. Die Gefahr, das dass Projekt zu einem Totalausfall wird ist dadurch geringer. Viele Grüße Olaf Radicke