JusCMS Architecture Workshop 2009-04-22/23

JusCMS,MPDL Im Projekt Jus CMS wurden drei mögliche Architektur-Optionen erarbeitet. Innerhalb des Architektur-Workshops werden diese drei Optionen der Projekt-Gruppe vorgestellt. Basierend darauf wird anschließend eine Entscheidung für eine Architektur-Möglichkeit getroffen.

Termin
Wann: 22. und 23. April 2009 Wo: MPDL, München

Teilnehmer
MPI Geistiges Eigentum, München: MPI Privatrecht, Hamburg: MPI Sozialrecht, München: '''MPI Strafrecht, Freiburg: MPDL, München: Contens:
 * Sylvia Kortüm
 * Heiner Leitl
 * Peter Weber
 * Gergana Stoyanova
 * Irina Arndt
 * Hans Martens
 * Henning Frankenberger
 * Jochen Jähnke (nur am 22.04.)
 * Malte Dreyer
 * Ulla Tschida
 * Natasa Bulatovic
 * Michael Franke (nur am 22.04.)
 * Juliane Müller
 * Herr Hoppe (nur am 22.04., bis einschl. Mittagspause)

Protokoll 22.04.2009
Teilnehmer: s.o. Protokoll: Irina Arndt

Begrüßung

 * Frau Kortüm heißt Gergana Stoyanova als Programmiererin im Kernteam willkommen
 * Frau Stoyanovas Vertrag beginnt am 4.5.
 * Frau Kortüm gibt eine Einführung in die Projektorganisation und das bisher Erledigte

Präsentation Contens 2.5 und 3.0

 * Herr Hoppe präsentiert live neue Funktionalitäten in der aktuellen Contens Version 3.1

Präsentation Prototyp Hamburg
Workflow Wissenschaftler:
 * Herr Martens und Frau Arndt präsentieren live auf dem Contens-Testsystem den Publikations-Prototyp des Hamburger MPIs:
 * auf jeder Wissenschaftlerseite kann eine Publikationsliste verlinkt werden
 * die Schablone der Publikationsliste enthält bereits 9 Publikationskategorien (vgl. Prototyp Hamburg)
 * Innerhalb dieser Kategorien können Publikationsobjekte hinzugefügt werden
 * pro Kategorie öffent sich eine Auswahl an Publikationstypen die zur Kategorie passen (vgl. z.B Aufsätze)
 * nachdem ein Publikationstyp ausgewählt wurde, öffent sich ein Formular mit aufüllbaren Feldern, in denen die notwendigen bibliographischen Informationen zur Publikation eingegeben werden können
 * nach dem Abspeichern des ausgefüllten Formulars wird das Publikations-Objekt direkt unter der ausgewählten Kategorie auf der Mitarbeiterseite angezeigt
 * die Anzeige erfolgt bereits in einem den juristischen Ansprüchen genügenden Zitierstil (unter Verwendung von Contens-Outputtypes)
 * über Publizieren kann der Mitarbeiter die Publikationsliste öffentlich machen (es werden nur die Kategorien angezeigt, die auch ein Objekt enthalten)

Workflow Tätigkeitsbericht:
 * über ein Python-Script wird ein kompletter Datenbankabzug angestoßen
 * es können die Publikationsobjekte eines bestimmten Jahres gefiltert werden
 * die gefilterten Objekt werden unter Verwendung der Contens-Outputtypes und diverser Formatvorgaben in eine korrekt formatierte und sortierte Publikationsliste (Dateiformat: InDesign) für den Tätigkeitsbericht umgewandelt
 * sämtliche Schritte können über eine GUI-Oberfläche per Knopfdruck ausgeführt werden

Workflow eDoc-Upload (MPG-Jahrbuch):
 * über ein Python-Script wird ein kompletter Datenbankabzug angestoßen
 * es können die Publikationsobjekte eines bestimmten Jahres gefiltert werden
 * die gefilterten Objekt werden in ein eDoc-konformes Format konvertiert
 * sämtliche Publikationsobjekte werden in einge eigene "Collection" auf dem eDoc-Server geladen
 * vor Veröffentlichung auf dem eDoc-Server müssen einge manuelle Nacharbeiten durchgeführt werden (vor allem Dublettenbereinigung)
 * sämtliche Schritte (inkl. Laden auf eDoc) können über eine GUI-Oberfläche per Knopfdruck ausgeführt werden

Nachteile des Prototyps:
 * keine Validierungsmechanismen und Hilfetexte in Eingabeformularen. Folge: fehlerhafte Dateneingaben, die manuell spätestens bei der Verwendung für Tätigkeitsbericht und Jahrbuch nachgebessert werden müssen
 * lange Ladezeiten bei Publikationslisten mit zahlreichen Objekten (mehr als 100)
 * keine Weiterverteilung an externe Systeme (z.B. SSRN, Google Scholar)

Fragen zu Contens
'''C1. Frage: Wie kann auf extern generierte HTML-Seiten referenziert werden? (Konzept 1)'''
 * alle Antworten von Herrn Hoppe (Contens) beziehen sich auf die aktuelle Contens Version 3.1

Antwort MPDL:
 * Pubman kann Publikationsdatensätzt sowohl in HTML als auch in XML ausgeben

Antwort Contens:
 * Variante Referenzierung: per Applikation kann auch nur referenziert werden (Nachteil: weder in Web-Such noch in Redaktionssuche verfügbar), Publikationsliste wird im Moment des Seitenaufrufs im Browser geladen
 * Variante Übertragung der HTML-Seiten per FTP: Wenn Server und Zielverzeichnis für die Ausgaben aus PubMan definiert sind, kann in die Wissenschaftler-Publikationsseite ein Applikationsobjekt eingebunden werden, das die Daten regelmäßig abholt (Vorteil: die Seiteninhalte sind auch in der Web-Suche verfügbar)
 * Applikationen können generell wie Objekte auf Seiten eingebunden werden
 * Aufwand zur Applikationserstellung: ca. 0,5 MT
 * Applikation kann in CF (Cold Fusion) oder anderen Sprachen geschrieben sein
 * Über die Applikation kann definiert werden, wie häufig die Objekte aktualisiert werden sollen: z.B. statisch, on the fly, oder in regelmäßigen Abständen (z.B. 1x pro Woche)
 * Applikationen sind einfach in künftige Contens-Versionen migrierbar, da "nur" die Umgebungsparameter angepasst werden müssen, nicht aber die Applikation
 * M

'''C2. Frage: Wie können externe Seiteninhalte in die Webserver-Suche (Collection) eingebunden werden? (Konzept 1)'''

Antwort Contens:
 * die redaktionelle Suche ist datenbankbasiert; wenn die Daten nicht in der Contens-Datenbank vorliegen können sie in der redaktionellen Suche nicht gefunden werden
 * Lösungsvorschlag: für externe Daten wird eine Extra-Collection in Contens definiert, über die eine eigene Suchmaschine läuft (z.B. lucene)
 * Die Webserver-Suche (Suchfunktion von außen für publizierte Seiten), erfasst externe Seiteninhalte auch ohne zusätzliche Collection oder eigenen Suchindex
 * M

'''C3. Frage: Wie können aus einer externen Datenbank generierte HTML-Seiten oder XML-Daten in das Contens-System übertragen bzw. eingebunden werden können (Schnittstellen)? (Konzept 1)'''

Antwort Contens:
 * Standardisierte Schnittstellen existieren bisher nicht
 * Http-requests auf externe Sever sind jedoch schon für Kunden umgesetzt worden
 * wenn die empfangenen Daten im XML-Format vorliegen, können sie von Contens verarbeitet werden (daher Bevorzugung der PubMan-Ausgabe als XML)
 * es werden bisher keine Standards zur Beschreibung von Daten unterstützt; dies könnte aber entwickelt werden

'''C4. Frage: Wie ist eine Eingabe der Publikationsdaten in das CMS und eine Übertragung in die Publikations-Datenbank der MPDL möglich?(Konzept 2)'''

Antwort Contens:
 * Grundsätzlich können Objekte (auch einzeln) als XML exportiert werden
 * XML-Ausgabe von Objekten in einer bestimmten Form kann entwickelt werden
 * per Web-Service können Objekte an PubMan weitergegeben werden, augelöst z.B. durch die Aktion des Publizierens; generell kann derContens-Distributionsprozess auch zur Datenübertragung genutzt werden
 * Validierunsprozess:
 * denkbar wäre ein Ablauf, bei dem ein Objekt als XML an das externe System geschickt wird (PubMan), das externe System eine Fehlermeldung ausgibt, diese Fehlermeldung von Contens weiterverarbeitet wird und eine Benachrichtigung des Objekt-Autors auslöst
 * das Contens-eigene Messaging kann auch für die Verarbeitung externer Meldungen genutzt werden
 * Anpassung = Entwicklungsaufwand wären jedoch in jedem Fall notwendig
 * Sonderentwicklungen werden auch in künftigen Versionen gepflegt und unterstützt

'''C5. Frage: Wie ist eine Eingabe der Publikationsdaten in die Publikations-Datenbank der MPDL und einer Übertragung in das CMS möglich?(Konzept 1)'''

Antwort Contens:
 * eine Ausgabe der Publikationsdaten als Contens-konformes Objekt (bzw. Umwandlung in ein solches Objekt = Parsing) hat Performance-Vorteile
 * diese Variante wäre auf Contens-Seite mit nur wenig Entwicklungsaufwand zu implementieren
 * Vorteile: Publikationsdaten können benutzt werden, als wären es lokal erzeugte Objeke; die Anzeigehoheit liegt auf Contens-Seite
 * M

'''C6. Frage: Welche Schnittstellen zu Übertragung/Synchronisation von Daten stehen zur Verfügung?(Konzept 1 + 2)'''

Antwort Contens:
 * XML wird als "Standard"-Import/Export-Format verwendet- in Kombinationen mit Diensten wie http requests (Abfrage), Web Services oder FTP (Datenlieferung)

'''C7. Frage: Ist das Kopieren von Objektklassen möglich? (Konzept 2)'''

Antwort Contens:
 * in der neuen Contens-Version: ja (über die Export/Import-Funktion)

'''C8. Frage: Können Hilfefunktionen bei Content-Typen integrierte werden? (Konzept 2)'''

Antwort Contens:
 * Einbindung von Hilfetexten ist grundsätzlich möglich- einfacher als in Version 2.5

'''C9. Frage: Wie können Validierungsmechanismen für Content-Typen implementiert werden? (Konzept 2)'''

Antwort Contens:
 * es können eigene Javascript-Funktionen geschrieben und flexibel an unterschiedlichen Stellen einer Objektklasse eingehängt werden

'''C10. Frage: Wie gut ist die Performance bei Eingabe von über 200 Publikationsdaten auf einer Seite? (Konzept 1 + 2)'''

Antwort Contens:
 * Problem der Performance in aktueller Version nicht mehr so akut (grundsätzlich geänderte Architektur)
 * bei der Verwendung eines relationalen Datenmodells zusätzlich deutlicher Performancegwinn

'''C11. Frage: Kann ein aktuelles Contens-Testsystems bereitgestellt werden?(Konzept 1)'''

Antwort Contens:
 * kann von Contens installiert werden
 * denkbar ist eine Installation als weitere Instanz in der aktuellen Umgebung
 * 2.5 und 3.0 können parallel auf einem Server installiert werden
 * Installation wird auf Railo Cold Fusion Server aufsetzen (Alternative zu Adobe Cold Fusion Application Server)

Vorschlag Contens: relationales Objektmodell für Publikationsobjekte
 * Haltung der Publikationsobjekte getrennt von anderen Contens-Objekten (für jedes Institut einzeln oder für alle fünf gemeinsam: als eigene collection oder außerhalb von Contens)
 * Verwendung eines eigenen relationalen Datenmodells (in Contens 3.1 ist das neue Objektmodell sowieso relational)
 * Ablauf: http-request auf PubMan-Server, Datenlieferung in XML durch PubMan (per FTP), Parsing der Daten, Mapping auf Objektstruktur (generische oder relationale Objektstruktur)
 * Vorteile:
 * Performanz
 * M

Präsentation eSciDoc-PubMan

 * Herr Dreyer stellt die PubMan-Funktionalitäten live anhand der aktuellen Version 4.1 vor.


 * Frau Bulatovic präsentiert den eSciDoc/PubMan Hintergrund: Präsentationsmaterial


 * Frau Bulatovic führt live den Datenexport für das MPI Nijmegen vor, das diesen bereits produktiv für ihr CMS einsetzt

Fragen zu eSciDoc-PubMan
'''P1. Frage: Ist die Datenmigration eDoc/PubMan problematisch?''' Antwort MPDL:
 * Basis der Fragen sind die Kritikpunkte der AG Technik aus 2007
 * aufgrund der heterogenen Nutzung von eDoc durch die Institute waren individuelle Konvertierungen notwendig
 * es wurde eine Checkliste entwickelt, die vor künftigen Migrationen mit den Instituten durchgegangen wird
 * Migrationsaufwand: ca. 7 bis 10 Wochen für erste Institut (MPI PL)
 * PubMan ersetzt die eDoc-Collections durch "Organizational units", denen ein anderes Konzept zugrunde liegt; in diesem Punkt ist bei der Migration mit gründlichen Vorüberlegungen und höchstwahrscheinlich manueller Nacharbeit zu rechnen

'''P2. Frage: Ist die Grundkonzeption von eSciDoc stimmig (Probleme der Eindeutigkeit, Performanz, Konsistenz)?''' Antwort MPDL:
 * in XML beschreiben sich alle Daten vollständig selbst, dadurch ist mehr Transparenz als bei Datenbankobjekten gegeben
 * Performanzprobleme konnten gelöst werden (z.B. durch cashing der XML-Daten in relationalen Datenbanken); Aufbau eines items je nach Serverleistung in einer Millisekunde
 * Speicherformat der Daten ermöglicht eine unproblematische Unterstützung weiterer Standards

'''P3. Frage: Ist das System erweiterbar? Wie sieht es mit Updates / Upgrades aus?''' Antwort MPDL:
 * Ja, ist es: im Rahmen von Releases, die stabile Punkte in der Entwicklung von eSciDoc darstellen
 * es gibt Haupt- und Nebenreleases in regelmäßigen Abständen
 * die Versionierung bei Kunden war anfangs problematisch, ist aber verbessert worden und wird weiter optimiert

'''P4. Frage: Wie sieht es mit der Nachhaltigkeit der MPDL aus? Ist der Know-How-Transfer garaniert?''' Antwort MPDL:
 * am 15.7.09 wird über eine Entfristung der MPDL entschieden
 * sicher finanziert sind alle Stellen bis Ende 2011
 * einen echten Fallback-Plan gibt es nicht

'''P5. Frage: Ist die eindeutige Definition von Daten gewährleistet?''' Antwort MPDL:
 * Ja, jeder Datensatz erhält einen Persistent Identifier (PID)

'''P6. Frage: Läuft eSciDoc zuverlässig?''' Antwort MPDL:
 * eSciDoc fungiert als MPG-Gesamt-Repository und muss somit höchste Ansprüche in puncto Verfügbarkeit und Zuverlässigkeit erfüllen
 * es wurde unter Berücksichtigung der Zukunftssicherheit sehr performate Hardware erworben
 * alle Server stehen bei der GWDG
 * Fedora (bei dessen Ausfall eSciDoc generell nicht mehr funkional wäre) ist derzeit noch in das SAN der GWDG eingebunden, soll aber in Kürze in das RAID-1-System wechseln (RAID)

'''P7. Frage: Sind unsere Zweifel am Projekt "Fedora" berechtigt?''' Antwort MPDL:
 * Fedora wird weltweit hundertfach eingesetzt- auch mit Objektzahlen im Millionenbereich
 * Fedora hat sich mittlerweise als Repository-Software etabliert

'''P8. Frage: Unterstützt eSciDoc/PubMan das OAI-Protokoll?''' Antwort MPDL:
 * Ja

'''P9. Frage: Ist eSciDoc/PubMan DINI-zertifiziert?''' Antwort MPDL:
 * Zertifizierung noch in 2009
 * MPDL ist DINI beigetreten und in diversen Arbeitsgruppen aktiv

Darstellung der einzelnen Architektur-Optionen mit Diskussion der Vor- und Nachteile

 * in Vorbereitung auf den Architektur-Workshop wurden verschiedene CoLab-Seiten vorbereitet, die als Handout an alle Anwesenden gehen:
 * die Architekturoptionen in kurzer Übersicht (JusCMS Architecture Options Overview)
 * die Architekturoptionen in grafischer Darstellung (JusCMS Architecture Options Figures)
 * die aus allen bisherigen JusCMS-CoLab-Seiten zusammengetragenen Vor- und Nachteile der Optionen (JusCMS Architecture Options Advantages/Disadvantages)


 * das Handout bildet die Diskussionsgrundlage
 * es werden Varianten von Konzept 1 (Primäre Datenhaltung in eSciDoc/PubMan) und Konzept 2 (Primäre Datenhaltung im CMS) des Projektantrags diskutiert
 * Konzept 3 (3.1 Datenhaltung in eigenständiger SQL-Datenbank als Repository, 3.2 Datenhaltung in "eigenem" PubMan-Repository) wird aus folgenden Gründen abgelehnt- und daher nicht diskutiert:
 * teuerste, aufwändigste und fehleranfälligste Lösung: drei Systeme statt zwei, Anbindung in zwei Richtungen (gilt für 3.1, 3.2)
 * "Neuerfindung des Rades" (gilt für 3.1.)
 * Abkopplung von Upgrades und Erweiterungen der allgemeinen eSciDoc/PubMan-Version- hierdurch dauerhaft erhöhter Pflegeaufwand (gilt für 3.2)

Konzept 1.1 (Eingabe durch Wissenschaftler, Ausgabe der Publ. als HTML-Seite)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 1.1 entschieden
 * Anforderung der Unabhängigkeit der Systeme ist nicht efüllt: bei einem Wegfall von PubMan wären die Daten nur eingeschränkt lokal verfügbar
 * Anforderung der flexibel anpassbaren Listen mit Ausgabe als HTML-Seite nicht erfüllbar
 * Anforderung der nur rudimentären Eingabe durch den Wissenschaftler und Ergänzung durch eine zentrale Stelle ist nicht erfüllt
 * Anforderung, dass keine Komforteinbußen für den Wissenschaftler stattfinden sollen, ist nicht erfüllt: eine vollständige Vorschaufunktion wäre nicht verfügbar

Konzept 1.2 (Eingabe durch Zentrale Stelle, Ausgabe der Publ. als HTML-Seite)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 1.2 entschieden
 * Anforderung der Unabhängigkeit der Systeme ist nicht efüllt: bei einem Wegfall von PubMan wären die Daten nur eingeschränkt lokal verfügbar
 * Anforderung der flexibel anpassbaren Listen mit Ausgabe als HTML-Seite nicht erfüllbar
 * Anforderung der vollständigen, komfortablen Dateneingabe durch den Wissenschaftler ist nicht erfüllt
 * Anforderung, dass keine Komforteinbußen für den Wissenschaftler stattfinden sollen, ist nicht erfüllt: eine vollständige Vorschaufunktion wäre nicht verfügbar

Konzept 1.3 (Eingabe durch Wissenschaftler, Ausgabe der Publ. als CMS-Objekt)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 1.3 entschieden
 * Anforderung der nur rudimentären Eingabe durch den Wissenschaftler und Ergänzung durch eine zentrale Stelle ist nicht erfüllt

Konzept 1.4 (Eingabe durch Zentrale Stelle, Ausgabe der Publ. als CMS-Objekt)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 1.4 entschieden
 * Anforderung der vollständigen, komfortablen Dateneingabe durch den Wissenschaftler ist nicht erfüllt

Konzept 1.5 (Eingabe durch Wissenschaftler ODER Zentrale Stelle, Ausgabe der Publ. als HTML-Seite)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 1.5 entschieden
 * Anforderung der Unabhängigkeit der Systeme ist nicht efüllt: bei einem Wegfall von PubMan wären die Daten nur eingeschränkt lokal verfügbar
 * Anforderung der flexibel anpassbaren Listen mit Ausgabe als HTML-Seite nicht erfüllbar
 * Anforderung, dass keine Komforteinbußen für den Wissenschaftler stattfinden sollen, ist nicht erfüllt: eine vollständige Vorschaufunktion wäre nicht verfügbar

Konzept 1.6 (Eingabe durch Wissenschaftler ODER Zentrale Stelle, Ausgabe als CMS-Objekt)

 * das Konzept 1.6 wird einer näheren Betrachtung unterzogen

Konzept 2.1 (Eingabe in Contens, Eingabe durch Wissenschaftler)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 2.1 entschieden
 * Anforderung der nur rudimentären Eingabe durch den Wissenschaftler und Ergänzung durch eine zentrale Stell ist nicht erfüllt

Konzept 2.2 (Eingabe in Contens, Eingabe durch Zentrale Stelle)
Ausschlaggebende Gründe:
 * es wird gegen das Konzept 2.2 entschieden
 * Anforderung der vollständigen, komfortablen Dateneingabe durch den Wissenschaftler ist nicht erfüllt

Konzept 2.3 (Eingabe in Contens, Eingabe durch Wissenschaftler ODER Zentrale Stelle)

 * das Konzept 2.3 wird einer näheren Betrachtung unterzogen

Protokoll 23.04.2009
Teilnehmer: s.o. Protokoll: Irina Arndt

Analyse der Abschlussdisskusion und erste Priorisierung der Architektur-Optionen

 * Ergebnis des Vortags: die priorisierten Architektur-Konzepte sind Option 1.6 und 2.3

Diskussion Konzept 1.6:

Bisher nicht genannte Vorteile:
 * Datenhaltung in PubMan in Utf 8 (Unterstützung sämtlicher Sonderzeichen)

Nachteile / Probleme:
 * 1. Ermöglichen einer echten Vorschau
 * 2. auf PubMan-Seite können Datensätze in Bearbeitung derzeit nicht bzw. nur sehr eingeschränkt exportiert werden (Export ist Voraussetzung für die Vorschaufunktion auf Contens-Seite)
 * 3. Arbeit in zwei Systemen: doppelte Anmeldung
 * 4. Einarbeitung in zwei Systme
 * 5. Weniger flexible Anpassung der Eingabformulare (PubMan Standards, Anpassung muss durch MPDL erfolgen)
 * 6. Weniger flexible Erweiterungsmöglichkeiten für neue Publikationstypen

Lösungsansätze für Nachteile:
 * 1. das Auslösen des Imports durch Click auf den Preview-Button könnte eine komfortable Vorschau ermöglichen
 * 2. Datensätze müssen grundsätzlich freigegeben/publiziert werden
 * 3. durch Einsatz von OAuth nur einmalige Anmeldung des Wissenschaftlers
 * 4. sowohl für die rudimentäre Eingabe als auch für die vollständige Eingabe durch den Wissenschaflter sollen Style-Vorgaben verwendet werden, die sich am Look & Feel der Contens-Oberfläche orientieren
 * 5. institutsspezifische Eingabemasken sind möglich, lediglich das zugrunde liegende Datenmodell muss einheitlich sein (Aussage MPDL)
 * 6. Wenn neue benötigte Publikationstypen bereits bekannt sind, können diese in den Anforderungskatalog aufgenommen werden und sind somit Projektbestandteil (z.B. Typ "Stellungnahme"); MPDL sieht Projekt als Anreiz die Flexibilität und Erweiterbarkeit des Systems zu erhöhen

Diskussion Konzept 2.3:

Nachteile (in Ergänzung zu den bereits zusammen getragenenen):
 * 1. Weiterentwicklungen und Services der eSciDoc-Infrastruktur können nicht genutzt werden, wenn PubMan nur als Archiv fungiert
 * 2. Technischer Ablauf der Rechteübergabe völlig unklar: Übergabe von Zusatzinformationen, die nicht Bestandteil des PubMan-Datenmodell sind, z.B. Upload-Angaben zu SSRN
 * 3. Zeichensatz für Objekte in neuer Contens-Version unklar (in Contens 2.5 kein Unicode)
 * 4. es ist unklar, wie sich Upgrades und neue Versionen auf den Export zu PubMan auswirken

Lösungsansätze für Nachteile: Exkurs SWORD (Simple Web-service Offering Repository Deposit):
 * 2./4. Herr Martens fordert bei Contens Konzept zum Datenexport an (inkl. Vorgehen bei Upgrades)
 * Herr Martens klärt die Frage nach dem Zeichensatz
 * Standard-Protokoll zum Datenaustausch zwischen Repositories
 * PubMan unterstützt SWORD
 * Vorteil Standard:
 * einfacherer Umgang mit Upgrades
 * Unterstützung eines Standards kann- im Gegensatz zu Sonderentwicklungen- sinnvoller in ein Produkt integriert werden


 * Nachteile SWORD:
 * Aufwand für Implementierung bei Contens: 15 bis 20 MT (Schätzung Herr Dreyer)
 * Unterstüzung eine Repository-Standards für Contens nicht attraktiv (abweichendes Kundenportfolio)
 * Fazit: wird nicht weiter verfolgt: zu teuer, zu aufwändig

Lösungsansatz für Anforderung "Unabhängigkeit der Systeme":
 * als Ergänzung des Konzept 1.6 könnte eine unabhängige externe Datenbank zusätzlich eingerichtet werden
 * dieses System bedient keinerlei Funktionen, sondern fungiert als reine Fallback-Variante
 * die MPDL kann einen Escrow-Service zum Einspielen in die Datenbank zur Verfügung stellen
 * Aussage Herr Leitl: dies würde seinen Anforderungen an eine Fallback-Variante genügen


 * die AG Technik wird diese Erweiterung des Architekturkonzepts noch mal besprechen
 * MPDL wird bei Bedarf gern ebenfalls an dem Gespärch teilnehmen (z.B. für Detailabklärung Escrow-Service)

Bearbeitung einer Matrix (priorisierte Optionen <-> Anforderungskategorien) zur Visualisierung geeigneter Architektur-Lösungen

 * Für die Optionen 1.6 und 2.3 wird eine Vergleichsmatrix unter Berücksichtigung der wichtigsten Anforderungen erstellt
 * Vergleichsanalyse.xls
 * Ergebnis: Option 1.6 (16 Punkte) liegt leicht vor Option 2.3 (12 Punkte) und deckt damit die Anforderungen etwas besser ab

Auswertung Matrix zur Visualisierung geeigneter Architektur-Lösungen
--Gergana 14:16, 12 May 2009 (UTC) Die Auswertung befindet sich auf der Seite zum jeweiligen Konzept.
 * Konzept 1.6 JusCMS_Architecture_Feasibility_Study_Concept_1.6
 * Konzept 1.6.1 (wie 1.6) JusCMS_Architecture_Feasibility_Study_Concept_1.6
 * Konzept 2.3 JusCMS_Architecture_Feasibility_Study_Concept_2.3

Weiteres Vorgehen

 * da das Matrix-Ergebnis für die Optionen eng beieinander liegen, kann noch keine eindeutige Präferenz für eine Option festgestellt werden
 * für beide Optionen wird eine CoLab-Seite erstellt (JusCMS Architecture Feasibility Study Concept 1.6, JusCMS Architecture Feasibility Study Concept 2.3), die folgende Bereiche enthält (zuständige Bearbeiter in Klammern):
 * Grafik (Frau Arndt)
 * Szenario (Frau Arndt, Frau Kortüm)
 * Vor- und Nachteile (Frau Kortüm)
 * funktionelle Anforderungen (Frau Tschida, MPDL)
 * Fragen (Frau Arndt, Frau Kortüm, Frau Tschida)
 * Termin Fertigstellung CoLab-Seiten: Anfang KW 20 (11.5.)


 * danach Klärung offener Fragen mit Contens (Herr Martens, voraussichtlich am 7./8.5.)
 * Videkonferenz AG Technik, MPDL und Projektleitung Vorschlag: 19.5.
 * Diskussion der zwei Konzepte und der "Fallback-Option" in der AG Technik auf Grundlage fertig bearbeiteten Seiten (Koordination Herr Leitl)
 * Abschluss der Diskussion in der AG Technik: bis Ende KW 21


 * Diskussionergebnisse gehen als Bericht zurück an die Projektleitung, Termin: 25.5. (Leitl)
 * Vorbereitung einer Entscheidungsvorlage für den Lenkungsausschuss im Board
 * Termin Treffen Board: 26.5.09


 * Weitergabe Entscheidungsvorlage Lenkungsaussuss
 * Termin Abgabe: ca Ende KW 22 des Boards
 * Entscheidung LA: innerhalb 1 bis 2 Wochen ab Abgabe