Die Entwirrung der Begriffsverwirrung


20.07.2016 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Da war's wieder: Sie haben in der Besprechung massiv Zeit verplempert, weil erst nach zehn Minuten klar wurde, dass Kollegin Müller was ganz Anderes unter „Komponente“ verstand als Kollege Schmid? 

Willkommen im Club! Offensichtlich verwendet jede Abteilung den gleichen Begriff in unterschiedlichen Bedeutungen. Und: Wenn Sie nun beschließen, ein Glossar zu schreiben und damit endlich mal die Begriffe zu schärfen und dem Chaos ein Ende zu machen – dann sind Sie gerade dabei, alles noch viel schlimmer zu machen. Warum ist das so?

In der IT-Branche liegt die häufigste Ursache für Begriffsverwirrung darin, dass wir einen eigentlich unspezifischen, allgemein verständlichen Begriff mit spezifischen Bedeutungen aufladen. Nehmen wir als Beispiel den Begriff Komponente – der Begriff existiert schon lange und hat eine umgangssprachliche oder jedenfalls traditionelle Bedeutung. Dazu Wikipedia:

Komponente v. latein. componens „das Zusammensetzende“

Das bedeutet: Wenn sich ein Ding aus mehreren Bestandteilen zusammensetzt, sind die Teile die Komponenten des Dings. So weit, so einfach. Chaotischer wird’s, wenn spezifische Bedeutungen hinzukommen. Dazu erläutert Wikipedia, dass der Begriff Komponente in vielen Kontexten verwendet wird, zum Beispiel in der Fahrradtechnik, der Chemie und auch in der Softwareentwicklung:

Komponente (Software), in der Entwicklung in Bezug auf Softwarearchitektur ein Teil einer Software 

Noch kein Begriffschaos, denn zum einen ist die Verwechslungsgefahr von Fahrrad- und Softwarekomponenten nicht groß – zumindest solange kein Meeting zwischen Fahrradherstellern und IT-Architekten stattfindet. Zum anderen wird der Begriff in den einzelnen Branchen einigermaßen ähnlich eingesetzt und entspricht der allgemeinen Bedeutung.

Folgen wir nun aber dem Wikipedia-Link Richtung Software-Komponente, steigt die Konfusionsgefahr allmählich an, wenn wir lesen, eine Komponente in der Software sei nur dann eine Komponente, wenn sie eine definierte Schnittstelle habe. 

Das folgende Gespräch fällt mir dazu ein. Frau Müller: „Unsere Software hat ungefähr zwanzig Komponenten, und es wird immer schwieriger, die Abhängigkeiten in den Griff zu kriegen“. Herr Schmid: „Das liegt daran, dass das gar keine Komponenten sind, das sind höchstens Module“.

Auf diesem immer noch moderaten Konfusionslevel verlassen wir Wikipedia und betrachten ein fiktives Projekt, das von Herrn Schmid und Frau Müller ins Leben gerufen wird, um Abhängigkeiten zwischen Software-Modulen (oder Komponenten) besser in den Griff zu bekommen.

Die beiden vereinbaren, dass Software-Komponenten zukünftig über dokumentierte REST-Schnittstellen kommunizieren und separat lauffähig sein müssen. Sie fügen dem Glossar des Projekts folgenden Eintrag hinzu:

Software-Komponente: Bestandteil einer Software-Architektur, die Schnittstellen über REST veröffentlicht, andere Komponenten über REST anspricht und separat deployable ist.

Jetzt ist das Chaos perfekt. Genau durch diese scharfe Definition ist es entstanden. Warum? Weil es einfach nur eine zusätzliche Definition ist, die alten Definitionen aber weiterhin existieren. Und noch mehr Bedeutungen eines Begriffs machen alles schlimmer, nicht besser. Denn was nun passiert ist folgendes: Es gibt weiterhin viele unterschiedliche Konzepte und Implementierungen für Software-Komponenten. Doch diese dürfen jetzt nicht mehr Software-Komponente genannt werden. Aber wie soll man sie dann bezeichnen? Natürlich könnte es passieren, dass sich die IT-Welt irgendwann auf genau ein Konzept für Software-Komponenten einigt. Dann wäre das Chaos vorbei, zumindest wenn auch alle Erinnerungen an die alten Konzepte  verblasst sind. Aber das ist weder realistisch noch wünschenswert.

Hilft eine Sprachpolizei? Jeder, der im Projekt das Wort Software-Komponente anders verwendet, muss fünf Euro ins Glossar-Schwein werfen? Hilft nicht. Erstens, weil neue Mitarbeiter ins Projekt kommen oder an einer Besprechung teilnehmen, die davon nichts wissen können. Und im Extremfall vor der Wahl stehen, in welches Glossar-Schwein sie zahlen müssen, weil es in ihrem eigenen Projekt auch eine Sprachpolizei gibt. Außerdem müsste Wikipedia auch noch verboten werden, da steht nämlich weiterhin und zu Recht die alte, allgemeine Definition. 

Wir fassen zusammen:

Jeder Versuch, einen bereits in einer breiten Bedeutung genutzten Begriff durch eine (Neu-) Definition schärfen zu wollen, vergrößert den Zoo der möglichen Bedeutungen und damit das Begriffschaos. 

Was sollte man stattdessen tun?

Die Lösung ist einfach: Wenn etwas Neues definiert wird, dann muss es einen eigenen, neuen Namen bekommen.

Ein Glossar zu führen ist ja prinzipiell eine gute Idee. Nur sollten darin die bekannten, allgemeinen Begriffe auch als solche erläutert werden – samt allen relevanten Gebrauchsformen des Begriffs. Wenn Sie darüber hinaus eine neue, spezielle und genau definierte Unterform eines Begriffs einführen, dann geben Sie dieser neuen Erscheinung auch einen Namen!  Zum Beispiel:

Müller_Schmid-Komponente (kurz SMKo): Eine Software-Komponente, die Schnittstellen über REST veröffentlicht, andere Komponenten über REST anspricht und separat deploybar ist. Erfunden von Frau Müller und Herrn Schmid.

Dadurch bleibt es möglich, die Begriffe auch in ihrer allgemeinen Bedeutung zu verwenden, denn jede andere Spezialisierung hat eben einen eigenen Namen. Folgendes Gespräch wird möglich: 

„Wie handhabt ihr Software-Komponenten?“ 

„Kraut und Rüben, jeder anders.“ 

„Aha. Bei uns gibt es jetzt nur noch SMKos.“  

„Kenne ich nicht, erklär doch mal SMKos.“ 

Namensgebung

Es ist nicht hilfreich, sich mit Synonymen, schlichten Übersetzungen („Component“ statt Komponente) oder Beschreibungen durchzumogeln: Eine „REST-Komponente“ kann jede Komponente mit REST-Schnittstelle sein. Dass hier ein viel spezifischeres Konzept gemeint ist, kann der Gesprächspartner nicht ahnen.

Ein neues, genau definiertes Konzept sollte einen Eigennamen haben, der es genau als solches kenntlich macht: 

„SMKos? Nie gehört, was ist das?“ 

„Unser neues Komponentenkonzept, mit REST und separatem deployment.“ 

Führt das nicht zu einer Explosion von Begriffen? Doch, tut es. In einer komplexen Welt mit einer unüberschaubaren Vielfalt von Dingen und Konzepten muss man mit einer entsprechenden Vielzahl von Begriffen leben. Denken Sie an die Biologen, die haben es auch nicht leicht mit über 2 Millionen Arten - und jede hat einen eigenen Namen. Damit können wir umgehen!

Es ist natürlich möglich, mit einem Scope, einem Namensraum, zu arbeiten, und der allgemeinen Bezeichnung den Scopenamen voran zu stellen. Der Scope könnte zum Beispiel die Firma sein. Dann gäbe es bei uns die itera-Komponente1. Das funktioniert zumindest theoretisch. Praktisch wird der Scope vermutlich meist weggelassen, weil er unhandlich ist. Ich persönlich finde Scope-Namen für menschliche Kommunikation auch unangenehm technokratisch – das ist eher was für XML-Parser. Aber das ist natürlich Geschmackssache.

Gute und schlechte Namen

Schauen wir uns ein paar Beispiele für gelungene und weniger gelungene Namenskreationen an:

Scrum: Perfekt. Ein in der IT neuer Begriff, entlehnt aus einer vollkommen anderen Domäne, so dass eine Verwirrung höchstens bei IT-Projekten für die Rugby-League entstehen kann. 

REST (Representational State Transfer): OK, weil in der Regel das Akronym verwendet wird und damit ein spezifischer Begriff für ein spezifisches Schnittstellenkonzept. Der Langname ist eine Beschreibung und somit heikel, aber wohl kryptisch genug um keine falschen Assoziationen auszulösen.

Lean Management: Ganz heikel. Eine Beschreibung, unter der sich jeder sofort etwas vorstellt, egal ob er die eigentlich spezifische Bedeutung (mit Kernprinzipien, Methoden, etc.) kennt. Begriffsverwirrung vorprogrammiert.

Jetzt wird’s unphilosophisch

Warum fällt es uns in der IT so schwer, neuen Ideen oder Konzepten neue Namen zu geben? Meine These: Weil es eine tief in uns verankerte philosophische Strömung gibt, die uns veranlasst, stets das Wesen, die Essenz hinter Dingen und Wörtern zu suchen: Was ist Leben? Was ist Sinn? Was ist Komponente? Diese Lehre wird als Essentialismus bezeichnet und geht auf Platon und Aristoteles zurück. Wie Karl Popper2 pointiert dargelegt hat, hat das im Bereich der Philosophie vor allem zu Verwirrung und Missverständnissen geführt. Deshalb ist da ja auch vieles so kompliziert! In den Naturwissenschaften dagegen wird anders vorgegangen, da dienen die Begriffe als Abkürzungen für sperrige Zusammenhänge, meint Popper. Und dort herrscht sehr viel weniger Begriffschaos.

Also: Seien Sie nicht sparsam mit Wörtern! Erfinden Sie Begriffe! Schaffen Sie neue Namen! Viele verschwinden eh wieder, weil die zugrundeliegenden Konzepte sich nicht durchsetzen. Probieren Sie's aus. Die englischsprachigen Länder, insbesondere die USA, haben da übrigens wesentlich weniger Hemmungen. Deshalb hat das Englische so unangenehm viele Worte, deshalb lassen sich viele Dinge aber auch so wunderbar prägnant ausdrücken. Und zumindest in der IT gibt der Erfolg den USA recht.


1Das machen wir ständig: Es gibt ein iteratec-EAM-Werkzeug „iteraplan“, ein iteraWiki und sogar eine Firmen-Jazz-Band namens „iteraBand“. Bei Komponenten haben wir es uns bisher verkniffen.

2Karl Popper, Die offene Gesellschaft und ihre Feinde, Studienausgabe. Band 1: Der Zauber Platons. ISBN 978-3-16-148068-3

Diesen Artikel bewerten
 
 
 
 
 
 
 
1 Bewertungen (100 %)
Bewerten
 
 
 
 
 
 
1
5
5
 

Artikel im Warenkorb:

0