SCHEMA Blog

Corporate Blog der SCHEMA GmbH

Über DITA (hinaus)

Hinterlasse einen Kommentar

Vorbemerkung
Auf der vorletzten und insbesondere auf der diesjährigen tekom-Herbsttagung (und das ist die größte Veranstaltung zu diesem Thema weltweit) gab es vermehrt DITA-kritische Vorträge, auch mein Geschäftspartner Marcus Kesseler hat selbst einen solchen gehalten. Sie finden ihn hier.

Teilweise gab es auf verschiedenen Blogs und auf Twitter emotionale Reaktionen darauf. Obwohl auch der DERCOM, dessen Vorstand ich bin, eine differenzierte Sichtweise auf die DITA-Diskussion in Zusammenarbeit mit Prof. Dr. Ziegler veröffentlicht hat, stellen die folgenden Kommentare meine persönliche Sichtweise zu dieser Diskussion dar. Darüber hinaus spiegeln sie auch unsere Meinung aus Produktherstellersicht wider.

Rückblick
Als wir von SCHEMA vor rund 20 Jahren auf der tekom-Tagung unser erstes Produkt präsentierten, war das Verständnis für dieses Produkt nicht wirklich groß: Warum sollte man Dokumente in wiederverwendbare Bausteine (Topics) aufspalten und dann in verschiedenen Lieferszenarien (Maps) über Links miteinander vernetzen? Und warum sollte man dieses komische XML dazu nehmen?

Noch vor 10 Jahren waren dann Teile des DACH-Marktes durchdrungen von der Idee, für jedes Projekt eine eigene DTD erfinden zu müssen. Dies hatte oft sehr kostspielige Folgen.

Anders formuliert: Niemand stellte zwar nun mehr die „Idee von XML“ in Frage, aber die Erkenntnis, dass der Hauptnutzen NICHT primär im Informationsmodell steckt, sondern durch die Funktionalitäten eines Component Content Management Systems (CCMS) entsteht, hatte sich noch nicht durchgesetzt.

Aktuelle Situation
Nach weiteren 10 Jahren werden wir heute nur zum Einbau einer speziellen DTD aufgefordert, wenn es auch wirklich nötig ist. Diese Fälle gibt es, sie werden dann aber vom Kunden gewünscht, wie umfangreiche Anpassungen und teilweise eben auch der Austausch der DTD. Die Regel ist aber inzwischen, SCHEMA ST4 einfach out-of-the-box zu nutzen.

Auf diesem Wege haben wir uns sehr umfangreiche und tiefgreifende Erfahrungen im Umgang mit DITA aneignen dürfen. Gelegentlich hört man, „uns“ – aber wahrscheinlich sind damit alle gemeint, die etwas Kritisches zu DITA sagen – würde das Know-how zu DITA fehlen. Ich möchte das bezweifeln.

Wir haben bei SCHEMA seit ungefähr zehn Jahren rund 30 Softwareentwickler mit der Weiterentwicklung von SCHEMA ST4 beschäftigt. Ich frage mich: Was haben die bloß die ganze Zeit gemacht, wenn das nun alles in der DITA-DTD drin stecken soll?

Meine Theorie dazu ist: Unsere Softwareentwicklung hat den Wünschen der Kunden entsprochen und die Funktionen ausgearbeitet, die von den Kunden gewünscht wurden. Und das war eine ganze Menge und hatte fast nichts mit dem Informationsmodell zur Content-Erfassung zu tun gehabt…

Wir haben in den letzten 20 Jahren bei SCHEMA, so wie wahrscheinlich jeder andere Redaktionssystem-Hersteller auch, ein eigenes Informationsmodell für den Inhalt entwickelt. Das sind zwanzig Jahre Evolution am Markt und das eigene Informationsmodell war nie ein Grund dafür, dass sich ein Kunde gegen SCHEMA entschieden hat. Die Kunden können inzwischen über eine Oberfläche auch selbst umfangreich erweitern und ändern.

Wenn ich heute auf DITA schaue, dann bin ich eigentlich irgendwie auch auf eine Art ein DITA-Fan. Ich finde die Idee von XML, Topics, Wiederverwendung usw. einfach bestechend gut. Es gibt viele Leute, die DITA wegen dieser zentralen Ideen gut finden. Das sind die DITA-Konzeptionalisten. Die DITA-Syntaktianer hingegen sind der Ansicht, dass man zur Umsetzung dieser Ideen „genau diese DITA-Syntax“ verwenden sollte. Ich glaube nicht, dass dies so sein muss.

Und dass dies ganz offensichtlich auch nicht der Fall ist, beweisen objektive betriebswirtschaftliche Fakten aus dem DACH-Markt. Der DACH-Markt gibt den Konzeptionalisten recht: Allein die Mitgliedsunternehmen des DERCOM, die wahrscheinlich rund 70% des DACH-Marktes abdecken, beliefern rund 1.300 Kunden, die seit Jahren nachweislich erfolgreich professionelles technisches Content Management betreiben und das weitgehend ohne DITA-Syntax. Die Idee ist gut, die Realisierung kann vielfältig sein.

Proprietär vs. Offener Standard
Die DITA-Syntaktianer sagen:

„Die Hersteller wollen doch nur ein (proprietäres) Produkt verkaufen, damit ein sog.“Lock-in“ beim Kunden entsteht, d.h. der Kunde wäre dann abhängig vom Hersteller, aber mit dem offenen Standard hingegen frei.“

Lassen Sie uns diese Vorwürfe einmal der Reihe nach durch gehen. Was steckt da alles drin? Hinter „die Hersteller wollen „nur“ etwas verkaufen“ steckt:

  1. Die Hersteller „wollen etwas verkaufen und zwar auf „Biegen und Brechen“ auch gegen die Interessen des Kunden.
  2. Der Datenaustausch ist erschwert oder unmöglich und dies deshalb, weil es sich um ein proprietäres Produkt handeln würde.

Ist das wirklich so? Und ist „proprietär“ (was ja letztlich nur „im Eigentum befindlich“ bedeutet) tatsächlich etwas Schlechtes?

Verkaufen
Lassen Sie mich mal kurz auf den „Vorwurf“ eingehen, wir wollten „nur etwas verkaufen“: Das hört sich einerseits fast so an, als ob „Verkaufen“ per se etwas Anstößiges sei. Auch ein DITA-Consultant will etwas verkaufen und zwar DITA-Schulungen, Workshops, DITA-Spezialisierungen etc.

In unseren Führungsgrundsätzen steht: „Wir haben zufriedene Kunden.“ Ob uns dies in jedem Fall vollumfänglich gelingt, sei dahingestellt, aber wir streben zumindest danach. Und ob Sie es glauben oder nicht: Nein, wir verkaufen einem Kunden, für den unser System nicht die passende Lösung darstellt, NICHT unser System wider besseren Wissens. Warum nicht? Weil wir alles auf eine sehr langfristige Zusammenarbeit auslegen und wir es uns nicht leisten können, systematisch an „unpassende Kunden“ zu verkaufen. Dann hätten wir nämlich „unzufriedene Kunden“ und das spräche sich herum. So einfach ist das.

Wir arbeiten auf „Jahrzehnte angelegt“ mit den Kunden zusammen. Wir entwickeln das Produkt systematisch weiter und wenn etwas nicht funktioniert, dann kann der Kunde bei uns anrufen und wir versuchen alles, um ihm weiterzuhelfen. Das kostet natürlich auch Geld. Aber deshalb geht es uns nicht darum, „nur“ etwas zu verkaufen.

Datenaustausch
Sind unsere Kunden wirklich von uns abhängig, weil Daten nicht ausgetauscht bzw. exportiert werden können? Und dies deshalb, weil unsere eigene Content-DTD verwendet wird? Und wären unsere Kunden freier, wenn es stattdessen die DITA-DTD wäre?
Machen wir es konkret: Wenn ein Kunde heute wirklich von SCHEMA ST4 weg will, weil es etwas Besseres gibt, was hat er dann für Möglichkeiten?

  1. Er kann sich die vorhandenen Informationen in einem der folgenden seitenorientierten Formate ausgeben lassen: FrameMaker, Word, InDesign. Die Layouts dazu kann er sich über eine wirklich coole grafische Oberfläche – den
    Page Layout Designer – zusammenstellen. Wer möchte, kann ganz ohne weitere Zusatzprodukte ebenso native PDFs
    erzeugen.
  2. Er kann sich – seit neuestem – über eine ebenso coole grafische Oberfläche mit dem Online Media Designer nahezu beliebige getaggte Exporte selbst erstellen also z.B. HTML, ePub, XML etc.

Wer jetzt sagt:

„Ja, aber das ist doch nicht damit gemeint. Es geht nicht um die Generate, sondern um die Quell-Informationen.“

dem kann ich folgendes anbieten:

  1. Jeder ArchitectClient enthält – offen zugänglich – ein Menü, um die XML-Inhalte samt aller Verwaltungsinformationen aus dem System als XML zu exportieren.
  2. Über die offengelegte API kann man sich bei Bedarf auch programmatisch und gezielt einzelne Inhalte exportieren.
  3. Und wer will, der kann – zu guter Letzt – sich die Daten einfach über das DITA-Export-Modul exportieren!

Man könnte auf diese Argumente sagen:

„Ja, aber das ist doch nicht gemeint. Dass man die Netto-Daten exportieren kann, ist klar. Aber genau davon ist man doch abhängig: Das sind doch die ganzen systemspezifischen Verwaltungsfunktionen, die implementiert wurden, wie z.B. die Versionsverwaltung, die Variantenverwaltung, die Sprachverwaltung etc. Diese ganzen Informationen sind nicht transportabel und man kann zwar die Netto-Daten von einem System ins andere transportieren, aber nicht wirklich den gesamten Datenbestand mit all den Verknüpfungen.“

Darauf kann ich nur sagen: Stimmt! Es gibt derzeit (und ich glaube auch nie) eine Möglichkeit derart hochspezialisierte Datenstrukturen verlustfrei und auf Knopfdruck von einem System auf ein anderes zu übertragen. Der Grund dafür sind genau die notwendigen Funktionen „oberhalb der DTD“, die eben mit den Nutzdaten verknüpft sein müssen, damit das gesamte System funktioniert. Und diese Funktionen sind der Grund, warum es Hersteller wie SCHEMA gibt: Die Funktionen stiften den Nutzen. Und dieser Nutzen ist der Grund, weshalb unsere derzeit rund 400 Kunden unser Produkt gekauft haben.

Anders herum betrachtet: Wenn jemand den Eindruck hat, dass er DITA-Daten von einem System auf ein anderes transportiert hat und „alles war da“, dann liegt das nur daran, dass beide Systeme praktisch keine Funktionen enthalten, die WIR für UNSERE Kunden in den letzten Jahren entwickelt haben, denn diese Funktionen sind definitiv NICHT in DITA enthalten – wir haben nachgeschaut 😉 – und werden auch nie auf einer (rein deklarativen) XML-Ebene abbildbar sein. Ganz einfach deshalb, weil diese „Ebene der Funktionen“ nichts mit XML (und DITA, DocBook etc.) zu tun hat.

Wenn ein DITA-CCMS-Anbieter auch all diese Funktionen implementiert – und das muss er wohl tun, wenn die Kunden nach und nach diese Funktionen wünschen – dann wird er das auf einer ganz genauso proprietären Ebene programmieren, wie alle anderen Hersteller eben auch.
Unsere Einschätzung ist, dass ein Content-Informationsmodell nur für ca. 5%-10% des Gesamtnutzens verantwortlich ist. Eine DITA-CCMS, welches auf dem Niveau Funktionen anbietet, wie es die Hersteller im DACH-Markt derzeit tun, ist genauso proprietär, einfach deshalb weil 90% der Funktionen nichts mit XML zu tun haben.

Jetzt könnte man fragen:

„Aber wenn Ihr System so toll ist, warum machen Sie es dann nicht einfach mit einer DITA-DTD? Dann brauchen Sie nicht ‚dagegen‘ zu argumentieren.“

Wir haben vor vielen Jahren erwogen, eine Standard-DTD wie z.B. Docbook als Content-Informationsmodell für SCHEMA ST4 zu wählen. Heute bin ich froh, dass wir es nicht getan haben. Wir hätten unsere Kunden niemals diesen Grad von Komfort, Innovation und Geschwindigkeit bieten können, den wir ihnen bieten konnten und können.

Wir wären ständig abhängig gewesen von einem Standardisierungsgremium, welches ggf. unnötige und verkomplizierende Dinge in den Standard hineindefiniert hätte, während die Kundenwünsche nicht wirklich abgebildet werden würden, weil alles viel zu langsam erfolgt oder schließlich vielleicht ganz zum Erliegen kommt.

Resümee
Unsere Kunden haben mannigfaltige Möglichkeiten jederzeit Daten zu importieren und zu exportieren. Auch in DITA. Die Möglichkeiten Daten in ST4 zu modellieren sind so umfangreich und der Funktionsnutzen so groß, dass der zusätzliche Nutzen den Inhalt in einer DITA-DTD zu schreiben hinterfragt werden darf. Die Idee von DITA ist ja gut. Wie gesagt: Ich bin ja auch DITA-Konzeptionalist. Aber:

  • Die DITA-Syntax bzw. eine DITA-DTD ist nicht notwendig, um die Ziele der DITA-Idee zu erreichen. Das beweist der DACH-Markt, den ich hier als international führend betrachte.
  • DITA ist einerseits als Erfassungs-DTD teilweise recht komplex (was auch in der DITA-Community erkannt wurde und weshalb es ein DITA-Leicht geben soll…) und zu spezifisch für Software-Dokumentation
  • andererseits ist DITA teilweise viel zu unspezifisch und das lässt sich wohl nicht komplett mit dem guten Konzept der Spezialisierung beheben. Kunden benutzen teilweise komplett andere DTDs als DITA….

Aber ganz abgesehen davon und um den Punkt noch einmal zu wiederholen: Der Nutzen eines CCMS hängt nur zu 5%-10% am Informationsmodell und hat damit nichts mit ‚DITA oder nicht DITA‘ zu tun. 90%-95% des ROI kommt durch Produktfunktionen, die völlig unabhängig von XML sind, zustande. Das „vollumfängliche Problem“ – nämlich ein professionelles Redaktionsteam mit einem funktionierenden System zu unterstützen – ist kein Problem, welches sich auf XML-Tags und DTDs reduzieren lässt und auch nicht primär davon abhängt. Die Diskussion um DITA (und um andere DTDs) lenkt vom Eigentlichen ab und so gesehen, argumentiere ich auch nicht gegen DITA, sondern über DITA hinaus.

PS: Wir haben im Übrigen auch einen DITA-Import-Filter im System… 😉

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s