Open Source, nicht immer der goldene Weg

Ich bin ein langjähriger Freund von Open Source, schon sehr lange und tendiere dazu , diese bevorzugt einzusetzen.

Aber auch wenn man mit Open Source viel erreichen kann und die Leistungsfähigkeit im Vergleich zu kommerziellen Produkten oft identisch ist, existieren Rahmenbedingungen, die von einem Einsatz abraten.

Die Gründe für eine Entscheidung gegen OSS sind oft nicht das Ergebnis eines direkten Vergleiches von Funktion und Kosten, sondern zu finden in der weniger komfortablen Integrationsfähigkeit in bestehende Infrastrukturen.

Und die Kosten, die man dann beim Einsatz von OSS spart, muss man anschliessend, manchmal auch mehrfach für anschliessende Integrationsleistungen aufwänden.

So z.B. im Bereich der Portalserver. Als ein intensiver Nutzer von Liferay behaupte ich, es existiert nahezu kein Grund, nicht auf Liferay zu setzen, wenn die Portalidee in einem Unternehmen eingeführt werden soll.

Ist dieses Unternehmen aber, wie z.B. viele Banken und Versicherungen, hochgradig abhängig von z.B. IBM Software wie Lotus Notes (Domino) im Bereich Email und CMS, Business Intelligence mit Cognos oder Filenet im Bereich DMS, ganz zu schweigen von ZOS als Hostbetriebssystem, dann ermöglicht der Einsatz des Websphere Portalservers eine deutlich einfachere und umfangreichere Integration.

Diese hier genannten Komponenten lassen sich auf dem visuellen Integrationslayer Portal mit Websphere sehr leicht zusammen führen. Eine Liferay Installation würde deutlich weniger Möglichkeiten – out of the Box – mitbringen.

In einem solchen Szenario machen sich die doch nicht geringen Initialinvestionen (z.B. Lizenzen) schnell bezahlt. Aber wie gesagt, hierbei ist nicht nur ein direkter Vergleich von funktionalen und nicht-funktionalen Anforderungen notwendig, sondern gerade die Enterprise Architektur Betrachtung im Unternehmen wichtig.

Wird beides vorher durchgeführt, dann ist man mit seiner Entscheidung i.d.R. auf der sicheren Seite – mit oder ohne Open Source!

Das Leben ist langer, ruhiger Fluss

Nicht nur das Leben, auch Software. Nicht immer ruhig, nicht immer lang, aber häufig beides. “Fluss” bedeutet bei Software dann häufig Pageflow, Workflow, Businessflow oder aber graphenorientierte Programmierung.

Sehr häufig und in der Vergangenheit wurden diese “flussorientierten” Programmieraufgaben properitär und immer wieder neu und individuell gelöst. In der jüngeren Vergangenheit wurden vermehrt und standardisiert und für einzelne Domains dieser “Flussaufgaben” eines Programmes freie und auch kommerzielle Frameworks angeboten. So z.B. JSF oder Struts für eine Pageflow-Aufgabe oder aber jBPM für die Bearbeitung von Business- und/oder Workflowaufgaben.

Weiterlesen