Wenn sich ein Unternehmen für eZ Publish entschieden hat, ist meistens die erste Frage: Welche Version setzen wir ein?
Unter Version versteht man hier nicht einfach 1, 2 oder 3. Sondern bei eZ unterscheidet man zwischen der Community und der Enterprise Version oder besser gesagt Edition. Die Frage ist stets, wo liegen die Hauptunterschiede, was sind die Vorteile und wo gibt es in der Praxis die größten Herausforderungen?

Laut eZ Systems gibt es vonseiten des Codes keine Unterschiede, beide Versionen sind identisch. Doch wo liegt dann der Unterschied und welche Version soll ein Unternehmen einsetzen? Ein eZ Partner ist grundsätzlich verpflichtet, seinen Kunden die Enterprise Version zu verkaufen. Es gibt in der Praxis nun jedoch häufiger den Fall, dass der Kunde zunächst einmal genaue Informationen wünscht, welche Unterschiede es gibt und wo die Vor- und Nachteile der beiden Versionen liegen um sich dann individuell zu entscheiden. Auf der eZ Publish Webseite werden zwar die Vorteile der Enterprise Edition aufgezeigt, jedoch wird es schwierig, wenn man sich detailliert zu den Unterschieden informieren möchte.

Ich möchte an dieser Stelle jetzt nicht im Detail die Vor- und Nachteile aufzeigen sondern eher erklären, wo die Probleme in der Entwicklung liegen und mit welchen Kosten ein Unternehmen im laufenden Projekt zu rechnen hat in Abhängigkeit der gewählten Edition. Denn die eigentlichen Schwierigkeiten liegen nicht zwangsläufig in unterschiedlichen Funktionen der beiden Editionen sondern eher in diversen Fallstricken bei der Entwicklungsarbeit.

5 Minuten eines Entwicklers mit einer Community Version

Stellen wir uns mal unseren Entwickler vor. Er sitzt einsam in einem Keller, gekleidet mit Anzug und Krawatte und trinkt seine Tasse Kaffee. Er tippt konzentriert auf seiner verschmutzten Tastatur, sein PC brummt vor sich hin und er programmiert eine Zeile nach der anderen für sein Kundenprojekt. Geschafft. Ein kurzer Test seines aktuellen Codes produziert jedoch einen Fehler. Mhm. Code checken, nochmal prüfen, umstellen und kurz probieren, aber nein. Es ist kein Fehler im Code und unseres Entwicklers! Das Problem muss woanders liegen.
Der erste Schritt unseres virtuellen Entwicklers, er schaut gleich in den Kernel nach wo der Fehler liegen kann.
Aus ist es mit den ruhigen 5 Minuten. Nach 2 Stunden weiß er endlich, wo genau das Problem liegt. Im Codekern gibt es einen Fehler, und er kann es ohne einen händischen Bugfix nicht beheben. Der Entwickler setzt sich mit dem jeweiligen Projektleiter zusammen und erklärt kurz und bündig wo das Problem liegt. Unser Projektleiter gibt dem Entwickler den Auftrag dies zu beheben und beim nächsten Patch zu berücksichtigen. Der Kunde wird erst nach der Bearbeitung informiert. Nach weiteren 3 Stunden informiert der Entwickler unseren Projektleiter das Problem sei behoben, jedoch könnte er nicht sicherstellen, dass es beim nächsten Patch nicht wieder auftritt und dann müsste er nochmal an den Code ran und wieder testen.

Zeitlich summiert sich das Ganze dann und wird zu einem echten Problem

  • 2 Stunden für die Fehlersuche
  • 30 min für die Kommunikation
  • 3 Stunden für den Fix
  • 1 Stunde fürs Testen

Investiert, in Summe: 6:30 Stunden – bei einem Stundensatz von 100 EUR macht das stolze 650 EUR. Es kann davon ausgegangen werden, dass beim nächsten Patch weitere Kosten hinzu kommen. Der Kunde erhält dann die Rechnung präsentiert. Nun fragt er sich vielleicht, wenn ich die Enterprise Version hätte, was würde der Entwickler machen, der genau das selbe Problem hat?

5 Minuten eines Entwicklers mit einer Enterprise Version

Nun stellen wir uns unsere andere – unsere Enterprise Entwicklerin vor. Mit einem T-Shirt bekleidet und ihrem MacBook Pro sitzt sie im sonnendurchfluteten Büro, trinkt Red Bull und nebenbei eine Tasse schwarzen Tee. Zeile um Zeile Code entsteht und beim ersten Test stößt sie auf das gleiche Problem wie ihr Kollege. Nachdem sie sichergestellt hat, dass es nicht an ihrem Code liegt, greift sie ohne zu zögern zum Hörer und kontaktiert den Projektleiter. Mit den Worten „Houston wir haben ein Problem“ leitet sie das Problem ein und erklärt es. Der Projektleiter meint, „kein Problem, ich klär das mit eZ“. Er ruft ganz entspannt bei eZ Systems an oder postet das Problem im Bugtracker. Drei bis vier Tage später bekommt er einen Bugfix und gibt diesen an unsere Entwicklerin weiter.

Der Fehler ist behoben die Kosten belaufen sich auf maximal 30 min für die Kommunikation. Der Kunde bekommt von der Angelegenheit gar nichts mit.

Fazit

Nein, ich möchte jetzt nicht sagen, dass nur PC-Entwickler in dunklen Kellern mit der Community Version programmieren 😉 Mein Fazit ist vielmehr, dass die Enterprise Version dem Kunden eine gehöriges Maß an Sicherheit gibt – Sicherheit nicht nur in der Entwicklungsphase des Projekts sondern auch im laufenden Betrieb des Systems. Gemeldete Fehler werden vomHersteller eZ Systems schnell und professionell behoben und die eigenen Entwickler werden nicht verzweifelt mit den Türen knallend den Raum verlassen und auf dem Hof auf einem Boxsack einschlagen.

https://blog.silversolutions.de/wp-content/uploads/2018/12/ez_dummy.pnghttps://blog.silversolutions.de/wp-content/uploads/2018/12/ez_dummy-150x150.pngDavid HohlB2B.praxisAnalyse,CMS,Strategie,TechnologieWenn sich ein Unternehmen für eZ Publish entschieden hat, ist meistens die erste Frage: Welche Version setzen wir ein? Unter Version versteht man hier nicht einfach 1, 2 oder 3. Sondern bei eZ unterscheidet man zwischen der Community und der Enterprise Version oder besser gesagt Edition. Die Frage ist stets, wo...Die e-Commerce B2B Experten bloggen über Händler-Shops, ERP, PIM und das integrierte CMS eZ Publish