Portal agil mit Liferay: Best Practices für die Portal-Integration

Transkript

1 Portal agil mit Liferay: Best Practices für die Portal-Itegratio Portal agil mit Liferay: Best Practices für die Portal-Itegratio Dieser Artikel zeigt, wie wir typische Best Practices für die Etwicklug i eiem agile Liferay-Portal-Projekt adaptiert ud agewedet habe. Eiige davo dürfte sigemäß auch auf adere Portalprodukte übertragbar sei. Wir beschreibe usere bevorzugte Portal-Etwicklugsasatz, der ebe Agilität auch auf Liferay- Besoderheite eigeht, ud erläuter, mit welcher Ifrastruktur wir diese uterstütze. Außerdem schilder wir, wie wir als Portal-Itegrator i Portal-Projekte mit mehrere beteiligte Parteie agiere. Ei eues Bakig-Portal User Fallbeispiel ist die Implemetierug eies eue Kude-Portals mit itegriertem Olie-Bakig ud -Brokerage bei eier mittelstädische Bak. Die bisherige Kude-Website der Bak war eie über viele Jahre gewachsee Eigeetwicklug eies IT-Diestleisters. Mit de gestiegee Erwartuge der Edkude isbesodere a de Komfort ud die Fuktiosvielfalt des Olie-Bakigs kote diese Lösug icht mehr Schritt halte. Die Neuimplemetierug auf Basis des Liferay Portal Servers sollte Abhilfe schaffe. We ei gazes Fiazportal eu gebaut wird, ist die Versuchug groß, die gesammelte Aforderuge ud eue Idee vollstädig ud idividuell umzusetze. Wird die Implemetierug mit Stadardsoftware i userem Fall dem Liferay Portal Server ud zusätzlich vo mehrere Implemetierugsparter durchgeführt, führt dieser Wusch leicht zu eiem Ergebis, das i pucto Wartbarkeit ud Betriebsfähigkeit verbesserugswürdig ist. Bidet ma die Projektbeteiligte jedoch i eie klar defiierte Itegratiosrahme ei ud schöpft die Stärke des Liferay Portal Servers bei der agile Umsetzug der Aforderuge aus, kommt ma zu eiem auch für die Fachseite sehr zufriedestellede Ergebis, ohe sich zuküftige Probleme aufzubürde. Eie gewisse Flexibilität bezüglich der Aforderuge seites des Kude ist dabei Voraussetzug. Nebe der Fachabteilug Electroic Bakig ud der itere IT ware a dem Projekt mehrere Parteie beteiligt: Ei IT-Diestleister, der de Auftrag hatte, die Olie-Bakig-Kompoete eu zu baue. Eie Olie-Agetur, die die Vorüberleguge der Fachabteilug i eiem Fachkozept beschreibe ud das Desig erstelle sollte. Ei Zulieferer für die Brokerage-Kompoete, die i das Olie-Bakig itegriert werde sollte. Produkthersteller (exter) ud Betreuer (iter) weiterer zu itegriereder Aweduge ud Services. Usere Aufgabe als Portal-Itegrator bestad dari, diese Parteie uter eiem gemeisame Projekt- ud Architekturrahme zu steuer sowie selbst das eue Portal aufzubaue ud alle Nicht-Olie- Bakig-Kompoete zu implemetiere. Best Practice 1: Qualität des Fachkozepts sicher We ei Kudeportal eu gebaut wird, gibt es oft zahlreiche Vorüberleguge ud Wüsche auf der Fachseite. Diese füge sich aber meist icht zu eiem schlüssige Kozept das fiale Bild muss erst och etstehe. Isbesodere da, we die alte Lösug bestimmte Schwäche hatte, werde sich mache Aforderuge aufgestaut habe, ohe bewertet ud eigeordet worde zu sei. Daher ist es sivoll, vor oder zu Projektbegi ei Kozept zu erstelle, das die grudlegede Struktur des Portals als Rahme für die Eiordug vo Idee ud Aforderuge festlegt. Dabei werde sowohl eue als auch viele i der Vergageheit liege gebliebee Aforderuge aufkomme, die gezielt hiterfragt werde köe. Mock-ups vo Portal-Seite eige sich dabei gut zur Klärug der grudlegede Aforderuge ud als Grudlage für das visuelle Desig. Ei (Java-)Portal-Server ist zuächst eimal eie Ablaufumgebug für Portlets. Portlets sid Java-Programme, die Fragmete vo HTML-Code erzeuge ud die zusamme mit adere Portlets ohe sich gegeseitig zu beeiflusse i eiem Portal-Server flexibel auf Web-Seite zusammegestellt werde köe. Der Portal-Server stellt dabei die grudlegede Ifrastruktur zur Verfügug. Darüber hiaus biete Portal-Server mittlerweile viele weitere, icht immer stadardisierte Dieste ud Fuktioe a. Das ist auch der Grud, warum Portlets meist ur i der Theorie portabel zwische verschiedee Portal-Server sid. Nebe Closed Source Portal-Server wie IBM WebSphere Portal Server ud Oracle WebCeter gibt es Ope-Source-Produkte wie JBoss Portal oder de i diesem Artikel betrachtete Liferay Portal Server. Liferay Portal Server kombiiert Liferay-Eigeetwickluge mit bewährte Ope- Source-Kompoete wie beispielsweise Apache Lucee. Die Fuktioalität vo Liferay lässt sich wie folgt grob glieder: Basis-Portal mit de Stadard-Portlet-APIs ud Liferay-APIs. Itegriertes Cotet-Maagemet-System ud Dokumetemaagemet-System. Mitgelieferte Portlets, die viele typische Portal-Awedugsfälle (z. B. Wiki, Fore, Blogs) abdecke. Zusätzlich istallierbare Pakete (sogeate Plug-is) vo Liferay oder Drittabieter, die Fuktioalität achrüste. Dabei ka es sich um Portlets oder adere Erweiterugsarte hadel. Kaste 1: Portal-Server ud Liferay i Kürze. 44

2 Das Kozept muss midestes auf eiem Niveau sei, das die grudlegede Kofiguratio des Liferay-Portals zu Projektbegi ermöglicht, da sich diese icht so agil äder lässt wie beispielsweise Seitestrukture ud -ihalte. I der durch das Kozept vorgegebee Struktur lasse sich die Details währed der Umsetzug ahad praktischer Aschauug gemeisam mit dem Kude ausarbeite. Das setzt atürlich voraus, dass der Kude die agile Vorgehesweise mitträgt. Typische Qualitätsmerkmale für ei solches Kozept sid: Vollstädigkeit: Für alle spezifizierte Elemete gibt es eie Beschreibug. Redudazfreiheit: Übergreifede Elemete wie beispielsweise Suche ud Navigatio sid eimal zetral beschriebe. Widerspruchsfreiheit: Sich a mehrere Stelle wiederholede Fuktioalität ist widerspruchsfrei beschriebe. Differezierug: Uterschiedliches Verhalte eies mehrfach auftauchede Elemets ist für de jeweilige Kotext korrekt beschriebe. Umsetzbarkeit: Die beschriebee Fuktioalität widerspricht icht der Philosophie der eigesetzte Stadardsoftware. Natürlich ka ma ei Fachkozept auch techikeutral schreibe steht das eizusetzede Produkt jedoch bereits fest, ist es viel effizieter, gleich auf die praktische Umsetzbarkeit zu achte. I userem Fallbeispiel wurde vo der Olie-Agetur ei eher visuell orietiertes Kozept erstellt, das och icht die otwedige Qualität für de Begi der agile Umsetzugsphase hatte. I eier ähliche Situatio würde wir empfehle, bei der Erstellug des Kozepts eie Facharchitekte mit Ketis der eizusetzede Portal-Software eizubide. Stufe Umsetzugsebee Liferay-Fuktioalität 1 Übergreifede visuelle Themes ud Layouts Apassug ud Seiteraster 2 Agepasste Vorlage für eizele Strukture ud Templates Ihalte ud dere visuelle Darstellug 3 Visuelle Darstellug vo Ihalte Portlet, das de Web-Cotet i Date plus eifache Fuktioalität kovertiert ud darstellt 4 Komplexere Fuktioalität mit Hookig eies Liferay-Portlets oder Ählichkeit zu bestehede eier Liferay-Fuktio Liferay-Portlets oder -Fuktioe 5 Komplexere Fuktioalität ohe Eigeetwickeltes Portlet Ählichkeit zu bestehede Liferay-Portlets 6 Fuktioalität, die aders icht Extesio (icht empfohle) umsetzbar ist Tabelle 1: Umsetzugsebee. Best Practice 2: Das visuelle Desig auf das Portal abstimme I viele Portal-Projekte ist eie Olie- Agetur für das visuelle Desig veratwortlich. Baut die Agetur das Desig dabei auf der grüe Wiese, verkompliziert das die Itegratio mit de bei Liferay mitgelieferte Portlets. Styles ud Formatieruge greife häufig icht, weil ihre Defiitio die durch Liferay i de Seiteaufbau eigebrachte Elemete icht berücksichtigt. Beispielsweise utze eiige Liferay-Portlets HTML-Tabelle. Falls das gelieferte Cascadig Style Sheet (CSS) auf eiem tabellelose Desig basiert, ist viel Itegratiosaufwad zu leiste. Bei eigeetwickelte Portlets ist das weiger problematisch, aber auch dort ka es durch die Vermischug mit de Liferay-Styles zu Probleme komme. Empfehleswerter ist es, der Agetur i eier Testumgebug frühzeitig Zugriff auf Beispiel-Liferay-Portlets ud -Seite bzw. auf das vo diese geerierte HTML zu gebe ud sie dafür passede CSS baue zu lasse. Best Practice 3: Die Umsetzug agil mache I usere Liferay-Projekte hat es sich bewährt, die Aforderuge des Kude so umzusetze, dass dieser rasch Ergebisse sieht ud sie verstehe ud bewerte ka. Nur we der Kude frühzeitig sieht, was er bekommt, ka er auch rechtzeitig eigreife, we etwas icht seie Erwartuge etspricht. Daher setze wir auf eie agile Vorgehesweise. Diese muss icht formal ud komplex sei aus der Struktur eies Portals ergebe sich atürlicherweise Sprit-Ihalte, die ma gemeisam mit dem Kude priorisiere ka. Eie der Stärke vo Liferay ist, dass es out of the box viel Fuktioalität mitbrigt, die bewusst auf mehrere Ebee äder- ud erweiterbar ist. Damit lasse sich Aforderuge so umsetze, dass das Ergebis für de Kude eierseits frühzeitig sichtbar wird, adererseits aber so apassbar bleibt, dass Feedback des Kude och eifließe ka. Zusamme mit eier etsprechede agile Vorgehesweise ergibt sich mehrfacher Nutze: Trasparez: Der Kude sieht frühzeitig, was er bekommt er ka sich ei Bild mache. Zusammearbeit: Basiered auf de Zwischeergebisse ka der Kude seie Aforderuge kokretisiere. Auf diese Weise steigt ach userer Erfahrug seie Bereitschaft, die Aforderuge im Detail flexibel azupasse. Wartbarkeit: Das Edergebis ist besser zu warte, da wir de Kude gegebeefalls zum Verzicht auf oder die Äderug vo Aforderuge bewege köe, die icht gut zum Portalstadard passe. Best Practice 4: Apasse statt eu implemetiere Etwicklug i Liferay ist auf mehrere Ebee möglich, die vo der rei visuelle Apassug bis zur Äderug des Portal- Quellcodes reicht. Wir strebe a, für die Umsetzug vo Aforderuge immer die höchstmögliche, also eifachste Ebee zu utze ud möglichst ahe am Portalstadard zu bleibe, um die Wartbarkeit ud zuküftige Updates icht zu erschwere. We sich eie Aforderug i leicht veräderter Form auf eier eifachere Ebee oder äher am Portalstadard umsetze lässt, diskutiere wir das mit dem Kude ud demostriere die veräderte Umsetzug bei Bedarf prototypisch. Zuächst kümmer wir us um das übergreifede visuelle Desig des Portals. Dafür 03/

3 Portal agil mit Liferay: Best Practices für die Portal-Itegratio baue wir ei gegebeefalls über Parameter kofigurierbares Theme, das de Seiterahme bereitstellt ud die Aforderuge a Navigatio ud Desig erfüllt sowie je ach Bedarf Layouts für verschiedee Seitetype ethält. Alles, was reie Ihalt darstellt, bilde wir als Web-Cotet ab. Dafür erstelle wir eie Struktur ud ei oder mehrere Templates, über die sich mit der Struktur agelegte Web-Cotets im Web-Cotet-Display-Portlet (Liferay-Stadard) darstelle lasse. Ist Fuktioalität erforderlich, die icht oder ur schwer als Template abbildbar ist, erzeuge wir ei eifaches Portlet, das de Web-Cotet i ei Dateobjekt kovertiert ud darstellt. Alles, was jetzt och übrigbleibt, ist vermutlich komplizierter. Aber vielleicht ka Liferay das bereits? Also prüfe wir, ob es ei mitgeliefertes Portlet gibt, das die passede Fuktioalität abietet, ud implemetiere dafür eie sogeate Hook. Hookig ist a viele Stelle i Liferay vorgesehe ud ermöglicht die Apassug ud Erweiterug des Portals ohe Äderug des Quellcodes. So sid beispielsweise Äderuge der Portal-JSPs (Java Server Pages) ud -Services machbar. Im Fallbeispiel utze wir diese Variate uter aderem für die Suche ud Formulare. Erst we all das icht reicht, etwickel wir selbst ei komplett eues Portlet. Die tiefgreifedste Erweiterugsmöglichkeit i Liferay ist die Extesio, mit der sich der Liferay-Quellcode direkt veräder lässt. Das ist eie sehr mächtige Optio, auf die wir aufgrud ihrer Nachteile jedoch grudsätzlich verzichte. Extesios erschwere durch de direkte Eigriff i de Quellcode küftige Updates ud jedes Deploymet eier Extesio erfordert eie Neustart des Servers. Stoße wir auf eie Aforderug, die ur als Extesio umsetzbar wäre, lote wir auf jede Fall mit dem Kude eie Äderug der Aforderug aus. Software-Lieferate existiert eie solche Umgebug, i der dieser seie Etwickluge teste ud gegebeefalls auch das Zusammespiel mit adere Kompoete ausprobiere ka. Die Veratwortug für diese Umgebuge liegt bei de Lieferate. Die Ergebisse der Voritegratio deploybare Portlets, Hooks oder Themes werde für die Itegratio bereitgestellt. Wir ee diese Ergebisse im Folgede Artefakte. Nachdem die Ergebisse aus der Voritegratio bereitstehe, werde sie auf der Itegratiosumgebug gesammelt. Hier werde alle Artefakte das erste Mal zusamme auf eier Umgebug istalliert. Daach prüfe wir i Itegratiostests das Zusammespiel der eizele Artefakte ud stelle fest, ob Wechselwirkuge auftrete. Auch we hier vorehmlich techische Aspekte getestet werde, empfiehlt sich ei Fuktiostest der fachliche Kompoete. Dadurch lässt sich sicherstelle, dass sich die Fuktioalität der Awedug wie spezifiziert verhält. Nach userer Projekterfahrug ist mit bekate Cotiuous-Itegratio-Produkte der Aufbau eies effektive Build- Prozesses möglich. Wir verwede dafür das Tool Jekis zusamme mit eiem Mave-Build-Prozess (siehe Abbildug 1). Wichtig ist die Verfügbarkeit eies Repositorys, i das sich alle Artefakte eistelle lasse. Über dieses fidet die Übergabe der Artefakte vo de Voritegratiosumgebuge zur Itegratiosumgebug statt. Im Folgede betrachte wir de Prozess ud die Uterschiede ud Umsetzug der eizele Umgebuge äher. Voritegratio Die Voritegratiosumgebuge bei de eizele Software-Lieferate diee i erster Liie dazu, auf kotrolliertem ud reproduzierbarem Weg de Quellcode i die Artefakte zu übersetze ud diese zu teste. Die geprüfte Artefakte werde aschließed mit eiem eideutige Bezeicher i das zetrale Repository eigestellt. Nach userer Erfahrug bewährt es sich, zu jedem Artefakt auch Javadoc- ud Quellcode-Budles bereitzustelle. Der Hitergrud ist, dass die (Wieder-)Verwedug des Artefakts möglichst eifach sei soll. Javadoc ud Quellcode helfe dem Beutzer des Artefakts, die Schittstelle ud Fuktioe besser zu verstehe. Zusätzlich ka ma sich mit Hilfe des Quellcodes bei Best Practice 5: Build ofte, deploy ofte Um bei der agile Umsetzug früh ud oft Ergebisse zeige zu köe, ist es otwedig, de Build-Prozess möglichst vollstädig zu automatisiere. So lasse sich mit gerigem Aufwad eue Versioe des Portals bereitstelle ud ausrolle. Der automatisierte Prozess bediet mehrere Umgebuge, die kurz eigeführt werde, begied mit de Voritegratiosumgebuge. Für jede im Projekt beteiligte Abb. 1: Überblick über die Umgebuge. 46

4 Itegratiosprobleme schell eie Überblick verschaffe ud erkee, woher der Fehler komme köte. Der letzte Schritt währed der Voritegratio ist die Übergabe der eue bzw. aktualisierte Artefakte a de Portal-Itegrator. Es muss sich dabei icht zwagsläufig um die aktuellste Versio hadel, falls diese och fehlerhaft oder uvollstädig ist. Die Übergabemeldug geschieht über ei XML-Dokumet, das die Artefakte ud Versioe beschreibt, die zur Itegratio vorgesehe sid. Techisch hadelt es sich hierbei um eie Mave-POM-Datei, die für jedes auszulieferde Artefakt eie Abhägigkeit defiiert hat. Itegratio Der Portal-Itegrator betreut die zetrale Umgebug für die Itegratio aller Zulieferuge. Diese Itegratiosumgebug sollte der Test- ud Produktiosumgebug möglichst ählich sei, wobei gewisse Eischräkuge bei Serverleistug oder Clusterig akzeptabel sei köe. Bei der Itegratio werde die gesamte Abhägigkeite, die vo de Software- Lieferate defiiert wurde, zu eier komplette Auslieferug aggregiert ud verpackt. Nebe der Auslieferug für die Itegratiosumgebug lasse sich hier mit de gleiche Abhägigkeite auch Testud Produktiosauslieferuge erstelle. Diese Auslieferuge uterscheide sich z. B. bezüglich der kofigurierte Datebak-Abidug. Auch die Art der Auslieferuge uterscheidet sich, de währed sich auf die Itegratiosumgebug vollautomatisch deploye lässt, ist dies auf Test ud Produktio icht gewüscht, da für diese Umgebuge i der Regel adere Vorgabe für Zugriffsberechtigug ud Veratwortug gelte. Für Test ud Produktio werde daher die Auslieferuge i eiem Order bereitgestellt. Die weitgehede Automatisierug ist i der Itegratio aus userer Erfahrug Pflicht. Die komplette Auslieferug sollte sich durch das Starte eies eizele Jobs erstelle lasse. Das achträgliche Bearbeite vo Artefakte ist auf jede Fall zu vermeide, weil sost der Prozess durch die mauelle Schritte uterbroche wird ud dies eie große Fehlerquelle sei ka. Abb. 2: Die Rolle des Portal-Itegrators. Itegratiostests Bis zu diesem Pukt wurde die Zulieferuge alle eizel oder i kleiem Umfeld getestet. Währed der Itegratio fide u auch die erste Tests des Gesamtsystems statt. Es ka immer Situatioe gebe, i dee es Wechselwirkuge zwische Artefakte gibt oder bei dee z. B. eue Style- Defiitioe icht überall passe. Auch die Abiduge a die Backed-Systeme sid erst i der Itegratiosumgebug gewährleistet. I userem Fallbeispiel-Projekt hat es sich etabliert, bei jeder Itegratio eimal quer über das Portal zu teste. Wir prüfe die gesamte Fuktioalität, rufe jedes Artefakt eimal auf ud stelle fest, ob es fuktioiert. Die Kommuikatio mit Backed- Systeme wird ebeso getestet wie die Schittstelle zu extere Dieste. Gibt es hierbei techische Probleme oder fide wir Fehler, behebe wir diese, bevor der Fachbereich das erste Mal testet. Auf diese Weise vermeide wir Frust bei de Tester, weil ichts fuktioiert. Auch überprüfe wir, ob die Vorgabe bezüglich Kofiguratio oder Loggig vo de Software-Lieferate eigehalte wurde. Best Practice 6: Rede, rede, rede I Projekte mit viele Stakeholder ist es sehr wichtig, dass die Sorge ud Wüsche aller beachtet werde. Es ist aber icht immer gaz eifach, die Aforderuge aus dem Fachbereich oder dem Betrieb mit de Produkt- oder Software-Lieferate abzustimme. Dies gilt isbesodere i Portalprojekte wie i userem Fallbeispiel. Die Etablierug der Rolle des Portal-Itegrators, die für das gesamte Portal a sich Veratwortug trägt, hat sich sehr bewährt. Als Portal-Itegrator habe wir bereits aufgrud userer Aufgabe direkt mit alle am Projekt beteiligte Stakeholder beim Kude sowie alle weitere Diestleister zu tu (siehe Abbildug 2). Wir erfahre also aus erster Had die Probleme ud Aforderuge aller Beteiligte ud helfe bei ihrer Bewertug. I der Regel gibt es i eiem Portal mehrere Wege, wie ma etwas umsetze ka, ud viele, wie ma es icht umsetze sollte, auch we es techisch möglich ist. A dieser Stelle muss der Portal-Itegrator auch Architekt sei. Wir helfe dem Kude, seie Aforderuge auf sei Portal abzustimme, ud mache Vorgabe a die Diestleister, wie die Kompoete is Portal zu itegriere sid ud welche betriebliche Aforderuge erfüllt werde müsse. I der Rolle des Portal-Itegrators ehme wir eie zetrale Platz i der Kommuikatio ud i der Auslieferug der Software ei ud zwar immer mit dem Ziel, alle Projektteilehmer zu etlaste, damit diese sich auf ihre Keraufgabe kozetriere köe. Fachbereich Als Portal-Itegrator sid wir erster Asprechparter des Fachbereichs, we beim Test etwas icht fuktioiere sollte. Um- 03/

5 Portal agil mit Liferay: Best Practices für die Portal-Itegratio gekehrt brauche wir vom Fachbereich Iformatioe, was zu teste ist ud wie gegebeefalls bestimmte Testkostellatioe herbeigeführt werde köe. Wir kümmer us zusamme mit dem Fachbereich auch um die Release-Plaug (Umfag ud Termie), we es dafür keie eigee Rolle gibt. Im Hiblick auf de Release-Umfag stimme wir ab, welche Teile aus fachlicher, techischer oder Itegratiossicht wa bereitgestellt werde müsse. Es ka zum Beispiel fachlich oder techisch sehr komplexe Artefakte gebe, die zur Risikomiimierug möglichst früh getestet werde müsse, obwohl es aus Itegratiossicht erst später otwedig wäre. Ebeso gibt es Artefakte, bei dee aus Itegratiossicht ei größeres Risiko besteht, dass sie icht fuktioiere. Hier ist eie ege Abstimmug mit alle Beteiligte otwedig. Sollte bei de fachliche Tests Fehler oder Probleme auftrete, köe wir de Fehler aalysiere ud eizele Artefakte zuorde. Da köe wir prüfe, ob die Kofiguratio korrekt ist ud gegebeefalls de Lieferate des Artefakts kotaktiere oder dem Fachbereich bestätige, dass es sich um eie fachliche Fehler hadelt, ud etsprechede Logauszüge zur weitere Aalyse bereitstelle. Diestleister We mehrere Diestleister (itere Awedugsetwicklug, Software-Lieferate, Olie-Agetur) am Projekt beteiligt sid, dere Etwicklugsaufgabe Abhägigkeite habe was i der Regel der Fall ist, muss der Portal-Itegrator für klare Abgrezuge sorge. Das betrifft weiger die Schittstelle zwische de Diestleister als vielmehr die übergreifede Portal-Vorgabe. Beim Portal-Desig gilt es, Etscheiduge zum Seiteaufbau ud zur Seitestruktur, zur Verwaltug vo Ihalte, zu Rolle ud Rechte, zum Schitt der Artefakte usw. zu treffe ud durchzusetze. Isbesodere we ei Diestleister weiger Portal-Erfahrug hat, ist immer darauf zu achte, dass die Lösuge zu der Portal-Architektur passe. Es ist besser, vorab die Radbediguge festzulege ud de Diestleister beim Aufbau der Voritegratiosumgebuge zu helfe, sodass diese auch dem Zielsystem etspreche, als erst bei der Itegratio zu prüfe, ob die Vorgabe eigehalte wurde. IT-Betrieb Ei weiterer, sehr wichtiger Parter des Portal-Itegrators ist der Betrieb. Nach der Abahme muss das Gesamtsystem vom Betrieb überomme werde. Darum muss ma frühzeitig über die Aforderuge des Betriebs Bescheid wisse. Gibt es beispielsweise Vorgabe für die Istallatio, Kofiguratio oder Auslieferug? Solle alle Artefakte i eier Auslieferug ethalte sei oder solle ur Deltas ausgeliefert werde? Welche Dokumetatio wird beötigt? Der Portal-Itegrator muss die Aforderuge sammel ud a alle betroffee Lieferate kommuiziere. Auch ist es sehr hilfreich, i de Itegratiostests zu prüfe, ob die Betriebsaforderuge eigehalte wurde. Das vermeidet de typisch hektische Aktioismus kurz vor Projektede, we auffällt, dass bis dato iemad diese Aforderuge geprüft hat. I diese Bereich gehört zudem die Abstimmug mit de Ifrastruktur-Teams. Welche Firewall-Regel sid otwedig? Wie müsse die Load-Balacer kofiguriert werde? Was ist mit Sicherheitsvorgabe? Wo fidet die SSL-Termiierug statt? Was passiert mit de Log-Dateie? Querschitt Beim Kude gibt es och weitere Querschitts-Aufgabebereiche, die vom Portal- Itegrator eigebude werde köe oder müsse. Dazu gehöre z. B. Qualitätssicherug, Traiig, Release-Maagemet, Partersysteme ud Compliace. Diese sid alle bei der Itegratio oder spätestes beim Test mit eizubeziehe. Die Autore Floria Schäfer (floria.schaefer@iteratec.de) ist IT-Architekt bei iteratec. Er uterstützt Kude bei Kozeptio, Desig ud Implemetierug vo IT-Aweduge. Seie Schwerpukte sid Java- Etwicklug ud Liferay Portal Server i alle Projektphase, vo der Kozeptio bis zum Betrieb. Fazit Nach userer Erfahrug wurde im Fallbeispiel-Projekt die Umsetzug des eue Portals durch de Fuktiosumfag ud die Apassbarkeit des Liferay Portal Servers deutlich erleichtert. Voraussetzug war allerdigs die Bereitschaft des Kude, die Stärke der Software optimal auszuutze (Nutzug der Bordmittel) ud dafür gegebeefalls die Aforderuge zu überdeke. Eie Idividualetwicklug wäre aufwädiger gewese, ohe ei besseres Ergebis zu garatiere. Die Flexibilität i de Aforderuge ud die Kozetratio auf Bordmittel brachte sigifikate Vorteile bei der Wartug ud Weiteretwicklug. Ebeso ützlich war ud ist die aufgebaute Etwicklugs- ud Deploymet-Ifrastruktur, die die Zulieferuge möglichst automatisiert zusammeführt. Die Rolle des Portal-Itegrators bestad eierseits dari, als Zuchtmeister die Aforderuge, die Architektur ud die Implemetierug zu steuer ud auf die Qualität zu achte. Adererseits fugierte der Portal-Itegrator als zetrale Alaufstelle bei Probleme sowie als Helfer ud Kümmerer. Die Strukturierug ud Steuerug sowie die Uterstützug habe etscheided zu eier Etlastug aller Beteiligte im Projekt beigetrage. Tjark Kalow (tjark.kalow@iteratec.de) ist Seior IT-Maagemet-Berater bei iteratec. Er uterstützt Kude bei der Kozeptio ud Umsetzug vo IT-Projekte. Seie Schwerpukte sid ebe Facharchitektur ud techische Assessmets das Aforderugsmaagemet, für das er iteratec-iterer Traier ist. 48