Konzepte,Ideen für Mandantenfähige Webportale

Hallo,
damit wir auch wissen, worüber wir sprechen ,hier mal ein Auszug aus der Wikipedia, der ganz gut umschreibt, was ich meine:

Als mandantenfähig wird Informationstechnik bezeichnet, die auf demselben Server oder demselben Software-System mehrere Mandanten, also Kunden oder Auftraggeber, bedienen kann, ohne dass diese gegenseitigen Einblick in ihre Daten, Benutzerverwaltung und ähnliches haben. Ein IT-System, das dieser Eigenschaft genügt, bietet die Möglichkeit der disjunkten, mandantenorientierten Datenhaltung, Präsentation (GUI) und Konfiguration (Customizing). Jeder Kunde kann nur seine Daten sehen und ändern.

Der Mandant ist die oberste Ordnungsinstanz in dem IT-System und stellt eine datentechnisch und organisatorisch abgeschlossene Einheit im System dar. Der Mandant strukturiert somit die Nutzung des Systems.

In einem mandantenfähigen System muss zwischen mandantenabhängigen und mandantenübergreifenden Daten und Objekten unterschieden werden. Mandantenabhängige Daten und Objekte sind Daten, Datenpräsentationen und Konfigurationen, die für jeden Mandanten individuell geregelt werden können. Beispiele sind Kunden, deren Kontoinformationen oder das Benutzerverzeichnis.
Zum Vergrößern anklicken....


Das Thema scheint auf jeden Fall eine spannende Diskussion zu werden...
 
Zuletzt bearbeitet von einem Moderator:
>>Das Thema scheint auf jeden Fall eine spannende Diskussion zu werden...

Hehe, da hast Du Recht.

Eine Anmerkung, die ich wichtig finde:

Auch wenn es nur mehrere Mandanten in einem Land gibt, sollte SW skalierbar implementiert werden.

D.h. abstrakt so aufgebaut werden, dass alles möglichst dynamisch und erweiterbar
aufgebaut ist. Da würde ich in jedem Fall so entwerfen, als ob es irgendwann
noch weitere Länder geben würde.

Eine Sache ist hier wie ich meine etwas anders rübergekommen als gedacht:
Ich sprach ja von Eigenimplementationen, welche u.a. eine Locale mit einbeziehen.
Ganz klar: Blödsinn, eine Multimandantenfähigkeit nur mit Locales machen zu wollen. Locales sind aber immens wichtig für das Zusammenspiel der einzelnen
Komponenten, welche eine Multimandantenfähigkeit umsetzen sollen.

Ich muss jetzt erstmal weiter ranschaffen, aber gucke am WE nochmal hier vorbei.
Bin mal gespannt, welche Ideen es noch so gibt?

Grüße, Tim
 
Was ich bis jetzt rausgefunden habe, scheinen viele CMS mandantenfähig zu sein.
Anscheinend bekommen dann wohl einige pro neuem Mandant gleich eine neue Datenbank spendiert. Das finde ich unschön. Alternativ kann man auch zusammengesetzte Primärschlüssel verwenden, allerdings weiß ich nicht, bis in welche Ebenen man die Schlüssel "mitnehmen" muss.
Für jeden Kunden eine Anwendungsinstanz aufzusetzten, fände ich persönlich auch viel besser, ist aber leider bei der Anzahl der erwarteten Mandanten nicht mehr praktikabel.
Ich find es nur sehr seltsam, das es so wenig Literatur o. ä. zu diesem Thema gibt.

Grüße,
Peter
 
pizza1234 hat gesagt.:
Für jeden Kunden eine Anwendungsinstanz aufzusetzten, fände ich persönlich auch viel besser, ist aber leider bei der Anzahl der erwarteten Mandanten nicht mehr praktikabel.
Zum Vergrößern anklicken....

Das klingt komisch. Wenn es nicht mehr skaliert für jeden Mandanten ein eigenes System aufzusetzen, wäre die Komplexität, Last und der Wartungsaufwand schon lang zuviel für ein monolithes Mandantensystem. Schon allein was die Performance angeht ist man mit vielen Einzelsystemen besser aufgestellt als mit einem. Stell dir vor, aus einem Bug im System entsteht eine Inkonsistenz in der Datenbank. Wenn du dadurch potentiell andere Kunden mit berührst möchte ich nicht in eurer Haut stecken. Natürlich liegt in einem so (mehrere Applikationsinstanzen) aufgestellten Projekt der kritische Punkt eher bei der Verwaltung der Appliktionsinstanzen. HIer hast du aber Separation of Concerns, d.h. du kannst den Themenkomplex in einem Extraprojekt abarbeiten und reduzierst die Komplexität des eigentlichen Projektes signifikant.

Google mal nach Product Line Engineering. Bei dem Thema stehen zwar so Dinge wie Variationspunkte in Softwaresystemen usw. im Vordergrund, allerdings geht das in eine ähnliche Richtung.

Gruß
Ollie
 
Hm, dem geb ich da mal Recht...Wenn sich viele Mandanten ein Anwendungssystem teilen, führt das eher zu einer Fehleranfälligkeit, bei der evtl. alle betroffen sind. Hm, müsste nicht tatsächlich die Trennung in verschiedene Anwendungsinstanzen tatsächlich schneller sein? Der Monolith wäre doch so aufgebaut, dass dort die verschiedenen Mandanten voneinander getrennt werden würden, was ebenfalls zu einem Overhead führen würde. Speziell wenn pro Mandant noch Anpassungen unterschieden werden müssen etc., könnte ich mir sogar vorstellen, dass das (Je nach Implementierung, Datenmenge etc.) sogar schlechter skaliert als die verschiedenen Instanzen mit Anpassungen.
 
Bin mich nun auch mal bei diesem Thema am einmischen :-)
Auf dem in meiner aktuellen Firma verweneten System wird mandantenfähigkeit DB-technisch mit einem DB-Schema pro Mandant gelöst (DB-Schema als Terminus in Verbindung mit Oracle)
Vor ein Paar Jahren hatte ich auch mal die Aufgabe (bei meinem vorangegangenen Arbeitgeber) eine Mandantenfähige Anwendung zu bauen. Dort habe ich alles auf einem DB-Schema gelöst also wurde im DB-Modell an den mandantenspezifischen Stellen unterschieden, wie schon hier auch in einem Beitrag angeklungen über Primärschlüssel etc.
Ich denke die eine oder die andere Variante ist zu wählen in Abhängigkeit der Menge der Tabellen im System bzw der Komplexität und vielleicht auch die Menge der Daten.
Bei komplexeren Anwendungen oder bei größeren Datenmengen sollte man vermutlich auf den Ansatz Schema pro Mandant zurückgreifen, wobei ich da keinerlei Richtwerte kenne, denn das war bei mir nur 'ne Bauchsache bzw. Frage der zur Verfügung stehenden Entwicklungszeit.

Thema Locales :
Aus meiner Sicht kann man Locales u.U. unabhängig vom Mandanten sehen, denn es könnte ja theoretisch sein, das ein Mandant Stellen/Filialen in verschiedenen Ländern hat, ebenso wie schon vorangegangen Beiträgen angesprochen in einem Land mehrere Mandanten sein können.

Berechtigunstechniken ....
Es gibt unter Oracle die Möglichkeit Rollen und Berechtigungen zu definieren und diese in der Anwendung zu verwenden.
Dies bedeutet aber AFAIK Abhängigkeit von einem bestimmten DB-System (Hersteller)
Eine andere Möglichkeit um hier flexibler sein zu können, ohne Code bei Wechsel auf ein anderes DB-System austauschen zu müssen, wäre vermutlich Rollen/Berechtigungen etc. in gewöhnlichen DB-Tabellen zu modelieren/hinterlegen und nur mit der fachlichen Anwendung (oder einer extra Administrationsanwendung) diese zu verwalten.
 
Im Prinzip habe ich mir genau sowas vorgestellt. Aus Kostengründen wird aber nur eine MySQL-DB verwendet. Rollen und Berechtigungen werden in Tabellen hinterlegt und eine extra Adminoberfläche, um die Mandanten zu verwalten. Allerdings ist auch genau das mein Problem, da ich nicht weiß, ob ich nun ein Schema pro Mandant oder Mandanten über Unique Constraints abbilden, wobei jetzt auch noch dazu kommt, das natürlich auch in den vorherigen Post eine Menge Sachen genannt wurden, die ich noch überhaupt nicht bedacht hatte. Fragen über Fragen:confused:!
Du hast nicht zufällig ein paar Literaturempfehlungen?
 
pizza1234 hat gesagt.:
Du hast nicht zufällig ein paar Literaturempfehlungen?
Zum Vergrößern anklicken....

Sorry, aber ich habe da keinerlei Litarturempfehlungen. Damals habe ich die Entwicklungsstrategie vorrangig auf die Zeit, die mir für die Aufgabe gegeben war, abgestimmt, und die war herzlich knapp. Man hätte sicher so einiges damals besser machen können, aber wenn man sowas auch das erste Mal macht und dann innerhabl kürzester Zeit mit für einem neue Techniken bewerkstelligen muss, ist das halt immer ein Kompromis.
Fragen die ich mir an Deiner Stelle auch einbeziehen würde
  • wie viel Zeit steht für die Entwicklung zur Verfügung gemessen an den dem/n Entwckler(n) neuen (unbekannten) Technologien, die zur Verwendungsabwägung
    stehen?
  • Wie groß ist das Entwicklerteam (Arbeitsteilung/zur verfügungstehende Zeit)
  • Wie viele Varianten wird es wohl pro Mandant geben dürfen/müssen bzw wie groß sind die Unterschiede der Datenstrukturen der verschiedenen Mandanten?
  • Wie groß sind die Datenmengen?
 
tim staeglich hat gesagt.:
>>
Auch wenn es nur mehrere Mandanten in einem Land gibt, sollte SW skalierbar implementiert werden.
D.h. abstrakt so aufgebaut werden, dass alles möglichst dynamisch und erweiterbar
aufgebaut ist. Da würde ich in jedem Fall so entwerfen, als ob es irgendwann
noch weitere Länder geben würde.
Zum Vergrößern anklicken....
Skalierbar ist immer gut :-)
Dies ist sicher aber auch eine Frage, wie Dein Gegenüber skalierbar versteht.
Tim versteht unter Skalierbarkeit hier Flexibilität/Erweriterbarkeit der Software. Skalierbarkeit kann aber auch bedeuten Steigerung der Rechnenleistung (z.B. soll die Anwendung Mehrprozessorfähig sein). Das Thema ist sicher eine Abwägung wert, denn sicher alles andere als trivial. Anderseits bin ich mir bezogen auf Webanwendung alles andere als sicher, ob dies Thema schon weitestgehend vom Web-Server abgedeckt wird.
 
takidoso hat gesagt.:
Skalierbar ist immer gut :-)
Dies ist sicher aber auch eine Frage, wie Dein Gegenüber skalierbar versteht.
Tim versteht unter Skalierbarkeit hier Flexibilität/Erweriterbarkeit der Software. Skalierbarkeit kann aber auch bedeuten Steigerung der Rechnenleistung (z.B. soll die Anwendung Mehrprozessorfähig sein)
Zum Vergrößern anklicken....

Skalierbarkeit ist eben nicht Erweiterbarkeit. Skalierbarkeit einer Software definiert sich über die Möglichkeit zusätzliche Last über zusätzliche (Hardware)resourcen auffangen zu können. Mit Erweiterbarkeit hat das nichts zu tun. Diese steht quasi orthogonal zu Skalierbarkeit. Nur weil mein System in OSGi geschrieben ist (hohe Erweiterbarkeit) skaliert es noch lange nicht.

Den Hinweis mal nach Produklinienentwicklung zu googlen, hatte ich ja schon gegeben. Die Ressource, die ich dazu kenne (http://www.se-radio.net/tags/product-lines) behandeln das Thema jedoch auf sehr abstraktem Level. Interessant währen halt CaseStudies von Unternehmen, dies sowas tun, sowas ist jedoch dann meist Betriebsgeheimnis ;). Zum anderen sind die Anforderungen IMHO an solche System auch sehr unterschiedlich, weshalb eine detaillierte Betrachtung nur in einer bestimmten Domäne Sinn macht.

Gruß
Ollie
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück