Spezialisierung auf ein CMS? Pro und Contra
Man passe seine Arbeit dem CMS an, für das man sich entschieden habe, ich gestern. Ein interessanter Aspekt (der so natürlich nicht sein sollte) und zu der Frage führt, ob man sich als Entwickler oder Designer einem einzigen System verschreiben sollte oder nicht.
Interessant nicht nur für den Entwickler oder Designer, der sich mal insgeheim hat denken oder sogar sagen hören, das ginge aber mit System XY nicht und man müsse da noch…
Im Prinzip ist die Beantwortung der Frage durch persönliche Abwägung der Vor- und Nachteile ganz einfach. Zusätzlich braucht man dann in jedem Fall noch eines, nämlich Zeit.
Spezialisierung: das ist mein System
Vorteile bei Spezialisierung:
- zunehmende Routine im Umgang mit dem CMS
- schnelles Erreichen eines Expertenlevels
- Überblick über die Möglichkeiten des Systems und verfügbare Erweiterungen
- Integration in die Community
- Etikett der Profiagentur
- erhöhte Glaubwürdigkeit bei Kunden
- Identifikation mit einem CMS
Nachteile einer Spezialisierung:
- Identifikation mit einem CMS
- Einschränkung hinsichtlich der Funktionalität
- Notwendigkeit zu Eigenprogrammierung bei eingeschränkter Funktionalität
Flexibel und unabhängig
Vorteile bei der Arbeit mit mehreren Systemen:
- Blick über den eigenen Tellerrand
- optimale Auswahlmöglichkeit entsprechend der Kundenanforderungen
- Ausfallsicherheit, Nachhaltigkeit falls Systeme nicht weiterentwickelt werden
- Unabhängigkeit
Nachteile bei der Arbeit mit mehreren Systemen:
- erhöhter Zeitaufwand für Einarbeitung
- erhöhter Zeitaufwand für das “auf dem Laufenden bleiben”
- Schwierigkeiten bei Integration in mehrere Communities
- Glaubwüdigkeit beim Kunden
- mangelnder Spezialisierungsfaktor
Entscheidungshilfe
Wenn man sich die Listen ansieht, findet man schnell Redundanzen. Widersprüche? Nicht unbedingt. Eher die Katze, die sich in den eigenen Schwanz beißt.
Thema Zeit und Einarbeitung
Ich bin der Überzeugung, um ein System anbieten zu können, muss man es kennen. Im Idealfall irgendwann aus dem FF, im Detail. Für mehrere Systeme macht sowas Mühe, kostet Zeit und bedeutet Arbeit. Da ist Vorlaufzeit gefragt. Diese kann sich aber rechnen. Man sollte davor nicht zurückschrecken, auch wenn es manch durchgetestete Nacht bedeuten kann. Wichtig ist dabei auch noch etwas anderes: die Schwierigkeit, unabhängig und neutral zu bleiben. Das kann gehen, aber man darf sich keiner “Philosophie” verschreiben. Das führt zum nächsten Punkt: Community.
Community: mehr eine Frage des offenen Codes?
Gerade, wer sich in der OpenSource Welt bewegt, wird feststellen, dass Communities das A und O sind. Bei kommerziellen, hoch proprietären Systemen wie Sharepoint ist das anders - ganz anders.
Community bei Open Source Systemen bedeutet für den Dienstleister einen klaren Vorteil, wenn es ums eigene Marketing geht und natürlich auch die Ressourcen. Wer sich engagiert, ist bekannt und kann damit zur eigenen Akquise beitragen. Engagement in der Community schafft Vertrauen - nicht nur beim Kunden. Community damit ein Vorteil für Dienstleister und Kunde.
Parallel dazu verschreibt man sich damit aber schnell jener “Philosophie”: ich bin Joomlaianer, ich bin TYPOlightler, ich bin Drupi oder wie auch immer sie heißen mögen. Vielleicht ist es bei TYPO3 anders: hier ist man schon eher Open Source Enterprise Dienstleister, - allein durch das Attribut TYPO3, das man sich auf seine Fähnchen schreiben kann. Wer bereit ist, sich Philosophien zu verschreiben und diese kritiklos mitträgt, läuft Gefahr, irgendwann den rostigen Nagel verkaufen zu müssen. Und als Überläufer tut man sich hart. Wer versucht, in Community Parallelwelten zu agieren, wird eventuell merken, dass dies sowohl aus Gründen der Glaubwürdigkeit als auch des Zeitfaktors ein schwieriges Unterfangen ist. Community damit unter Umständen ein Nachteil - in erster Linie für den Dienstleister.
Du bist doch mein Liebling…, oder?
Prinzipiell wäre das Ziel der Nutzung mehrerer Systeme eine totale Neutralität gegenüber mindestens 2-3 Content Management Systemen. Hier ist die Frage: geht das überhaupt? Wahrscheinlich verzichtetet man in der Realität auf den “sicheren Hafen” der Community. Man steckt viel Zeit in Eigenentwicklung, Try and Error. Nur so aber kann man den größten Benefit nutzen, den man aus der Einarbeitung in mehrere Systeme ziehen kann: Flexibilität, Unabhängigkeit und auf Kundenanforderungen hin zugeschnittene Lösungen
Alles in allem wird vor allem eines klar: die Ausweitung des eigenen Angebots hat zunächst seinen Preis im Zeitfaktor, denn eines darf nicht leiden: die Qualität.
Fehler? - eine subjektiv zusammengestellte Einschätzung
Es gibt einige Fehler, die passieren können:
- Wenn aus dem “Philosophie teilen” ein “sich einer Ideologie verschreiben” wird
- Fehlender Blick über den eigenen Tellerrand, auf laufende Technologien und die Featurelist von anderer Systeme
- Mangelnde Einarbeitung in ein System, fehlender Blick in die Untiefen des Codes
- Sich selbst verbiegen statt das CMS
- Bequemlichkeit im Sinn des “das hat doch immer gepasst”
Eines spart man sich ohne Spezialisierung auf jeden Fall:
Die Beantwortung der Frage nach dem “richtigen CMS”, der eierlegenden Wollmilchsau und der Variante, mit der alle Kundenwünsche aus dem Nichts erschlagen werden können.
Ganz abgesehen davon, dass es dieses System nie geben wird, kann die Zeit, um diese Frage zu beantworten und die Suche befriedigend (?) zum Abschluss zu bringen, bereits anderweitig durch umfangreiche Tests mehrerer Systeme und dem Abgleich mit typischen Kundenwüschen (kein Kunde ist gleich, aber nur wenige Anforderungen sind wirklich neu) genutzt werden.
Die Communities halte ich im Open Source Sektor -auch für die tägliche Arbeit - nicht nur für eine Bereicherung sondern für die notwendige Basis (für den Erfolg einer Software sind sie das sowieso). Hier muss es stimmen und hier muss man sich auch als Entwickler wohl fühlen.
Vielleicht klappt es dann, wenn auch alles andere stimmt, mit einem genauso gut wie mit mehreren CMSen im Gepäck?
