kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 4

Beispielhaftes Integrationsszenario

An dieser Stelle möchte ich Sie an die Hand nehmen und einmal im Geiste ein kleines Portalprojekt von den ersten Anfängen der Planung bis zur Übergabe durchzuspielen. Wir steigen bei den ersten Konzeptionen ein, behandeln die verschiedenen Player in einem Portalprojekt und geben Hinweise zur Planung der Architektur.

Aller Anfang ist leicht!

Zum Anfang eines Portal-Integrationsprojektes steht in jedem Fall eine allumfassende Aufnahme des Ist-Zustandes aller wichtigen Projektparameter.

Ein Portal erhebt im Idealfall sowohl den Anspruch der Abbildung von komplexen Geschäftsprozessen als auch ein auf die jeweiligen Rolle des angemeldeten Benutzers zugeschnittenes Anwendungsportfolio. Trotzdem sollte die Navigation simpel und eingängig bleiben und nicht überfrachtet sein.

Portale #5

Man unterteilt die Bedürfnisse in den der Benutzer abhängig ihrer verschiedenen Funktionen sowie Rollen und den Bedürfnissen des Unternehmens, was z.B. die Einbindung externer Dienste in die Portallösung oder das Design von kompletten Arbeitsabläufen betrifft. Oberste Prämisse sollte stets sein, dass sich das Portal den gegebenen Arbeitsabläufen und Unternehmensprozessen weitestgehend anpasst, nicht anders herum! Bei der Planung eines Portals spielen sowohl Kenntnisse über beabsichtigte Benutzerzahlen, Zielgruppen, Funktionen und Benutzer-Rollen und die benötigten einzubindenden Systeme in der Minimalkonfiguration eine wichtige Rolle.

Bereits während dieser Bestandsaufnahme sollte man die Repräsentanten des Kunden aktiv in den Ablauf miteinbeziehen, nach Erstellung eines ersten Entwurfs, was die finale Architektur betrifft sollte man stets das Feedback aller beteiligten Projektsponsoren einholen und danach erst die definitive Architektur festlegen.

Die genaue schematische und technische Festlegung des Systemkontextes im nächsten Schritt hilft ferner die Systemgrenzen und definierten Übergabeschnittstellen besser zu identifizieren und um etwaige Problemstellen oder zeitraubende Individualprogrammierung im Vorfeld zu erkennen. Zur Dokumentation und Visualisierung dieser Etappe eignet sich z.B. Visio oder jedes anderes Programm zur Chart-Erstellung.

Portale #6

 

Ziel dieser Aktion ist, alle Komponenten der geplanten Portallösung zu identifizieren und entsprechend zu klassifizieren. Neben Nutzer-Objekten sollte man Datenquellen, Externe Services und weitere Objektklassen kartographieren, wenn möglich inklusive aller wichtigen zusätzlichen Informationen.

Mögliche Objekttypen sind:

  • Process Designer – Jemand der als Verantwortlicher eines oder mehrerer Prozesse fungiert und der alle Informationen zu detaillierten Abläufen kennt.
  • Service Provider – Eine externe Instanz, die einen Dienst offeriert (dies kann entweder eine gekapselte Anwendung, ein einzelner Task als Teilbereich eines großen Dienstpakets oder sogar mehrere Dienste umfassen).
  • Service Requestor – Ein Objekt, welches passende Dienste in Anspruch nimmt. Dies kann entweder ein menschlicher Nutzer (human service requestor) oder eine Software (electronic service requestor) sein, die automatisch oder via Auslösung durch einen Trigger aktiv Dienste in Anspruch nimmt.
  • Service User – Ein Nutzerobjekt, welches Informationen bereitgestellt durch einen Service Provider konsumiert. Basierend auf dem Benutzerorientierten Ansatz, kann der Service User den jeweils passendsten Weg zur Erlangung der Information wählen Wie Service Requestors kann ein Service User entweder ein menschlicher Nutzer oder softwarebasiert sein.
  • External application/service – Wird verwaltet von einem dedizierten Service Provider. Kann entweder aus mehreren funktionell ähnlichen Diensten bestehen oder nur aus einem Ausschnitt (atomic service) eines übergeordneten Dienstes für eine bestimmte Aufgabe.
  • Platform Provider – Die Hauptinstanz, die als Vermittler zwischen allen anderen beteiligten Einheiten auf der Plattform fungiert. Für die Verfügbarkeit und Wartung zuständig.

 

Fortsetzung in Teil 5:

Im nächsten Teil geht es weiter um das Beispielhafte Integrationsszenario in Bezug auf die Funktionelle Sicht, die Anwendungsschicht und um den Systemkern.

Lesen Sie hier ab dem 18.09 den Teil 5

Share

Kommentare