In diesem ersten Beitrag zur Blogserie “Paradoxe IT” möchte ich auf folgendes Thema eingehen: Sollte man in der Softwareentwicklung auf Standards setzen oder eher eigene Problemlösungen entwickeln. Natürlich ist dies ein breites Feld. Es gibt die Abwägung Standard oder Eigenentwicklung auf vielen unterschiedlichen ebenen, z.B.

• Customizing einer Standardsoftware oder Komplette Eigenentwicklung
• Nutzung von (kommerziellen/open source) Softwarelibraries oder nicht
• Nutzung von Standardprotokollen (SOAP/HTTP) oder Definition eines eigenen Protokolls
• Eine Positionierung zwischen den beiden Extremen “Softwarearchitektur 100% nach Lehrbuch” und “Architektur speziell für den Einzelfall entworfen”
• Viele Andere…

Jede dieser Entscheidungen ist komplex und es gibt meistens gute Gründe für beide Entscheidungen. Deshalb ist es wichtig bei jedem Projekt über diese Fragen genau abzuwägen. Leider gibt es aber zu einzelnen dieser Entscheidung schwer ausräumbare Vorurteile, die sie auch noch über die Fragestellungen hinweg widersprechen. Ein typisches Beispiel: “Standardsoftware anzupassen ist billiger als eine komplette Eigenentwicklung” kombiniert mit “Unsere Ziele stellen ganz einmalige Anforderungen an Architektur und Softwareentwicklung”. Dass beide dieser Aussagen nicht immer richtig sind und sich auch noch widersprechen ändert nichts an der Tatsache, dass diese Kombination häufig anzutreffen ist.

Beispiel aus der Praxis

Was wurde vorgeplant?

Eine Teilaufgabe bei der Erweiterung der Systemlandschaft eines Kunden war die Anbindung der neuentwickelten Software an ein Legacy-System. So weit so unspektakulär. Das besondere war nun, dass für diese Anbindung ein spezieller Layer von einer Drittfirma entwickelt wurde um die komplizierte Schnittstelle des Legacysystems zu kapseln. Wunderbar möchte man meinen. Doch diese Chance, gleich eine Schnittstelle zu schaffen, die auf eine möglichst breite Standardbasis aufsetzt wurde nicht genutzt. Dies hätte die Anbindung heterogener Clients erleichert. Es wurde aber ein eigenes Protokoll entwickelt, da Web-Services “zu komplex” gewesen wären. Auf XML-Schema zur Beschreibung der Nachrichten wurde ebenso verzichtet (“unnötig”). Sie wurden stattdessen in einem Worddokument in Klartext erläutert. Schließlich sollten die Clients auch nur einfache XML-Nachrichten an einen bestimmten TCP/IP-Port auf dem Integrationsserver schicken.

Was wurde wirklich gefordert?

Wenn es sich bei der Integration wirklich nur um ein “Fire and Forget” von XML-Nachrichten gehandelt hätte wären all diese Entscheidungen vertretbar gewesen. Leider wuchsen, wie so oft, die Ansprüche schneller als die Technologie. Es stellte sich sehr schnell heraus, dass es sich bei der Integration zwischen Neu- und Altsystem um eine echte Komunikation handeln würde. Über den TCP/IP-Port musste dann nicht einfach eine XML-Nachricht “abgeladen” werden, sondern eine Methode wurde angesprochen. Im Zuge dessen mussten die folgenden Punkte geklärt und in das Customprotokoll eingebaut werden:

• Definition einer Serialisierung für verschiedene Datenformate.
  Die Frage ob booleans als [true, false] oder [1, 0] serialisiert werden sollten wurde mehrfach umgeworfen. Die Behandlung von Arrays wäre einen eigenen Blogeintrag wert.
• Sicherstellen der Nachrichtenintegrität und Schemavalidierung.
  Dies ist ohne ein explizites (XML-)Schema natürlich immer ein Ratespiel.
• Behandlung von Fehlern auf der Kommunikationsebene inkl. Retries.
• Behandlung von Fehlern auf Applikationsebene.
  Dies bedeutete natürlich auch das Definieren von möglichen Fehlerfällen, deren Datagrammen und erwartetem Clientverhalten. Alles in Klartext.
• Versionierung von Datagrammen und Methoden.
  Der Wunsch nach expliziten Schemata wurde nun lauter.
• Bandlung von Sicherheitsaspekten wie Authentifizierung und Autorisierung von Datagrammen und Methodenzugriffen.
  Dies wurde dann nur noch rudimentär umgesetzt, da es sonst zu komplex geworden wäre. Sessionhandling entfiel komplett.

Was kann man daraus lernen?

Dem genannten Beispiel liegt ein weit verbereiteter Trugschluss zu Grunde: “Die Aufgabe (hier verteilte Kommunikation) ist eigentlich ganz einfach. Wir brauchen deshalb keine komplizierten Werkzeuge einzusetzen (hier Web Services) .“

Natürlich gibt es an jedem Standard einiges zu bemängeln. Web Services sind hier keine Ausnahme. Dies liegt in ihrer Natur, da bei einer Standardisierung Kompromisse eingegangen werden müssen. Aber die Komplexität, die sie besitzen liegen zu einem großen Teil eben auch an dem Problem das sie lösen. Verteilte Kommunikation ist schwierig. Wenn man nun eigene Protokolle dafür entwickelt spart man sich die Auseinadersetzung mit den konkreten Produkten SOAP, WSDL etc. Dafür muss man nun aber selbst Antworten finden auf die Fragen die sie beantworten. Und diese Antworten müssen implementiert, getest und vor allem dokumentiert werden, sonst ist für den Kommunikationspartner das Protokoll noch unverständlicher als ein Standard.

Probleme zu ignorieren hilft hier auch nicht weiter. Die Aussgage “Wir brauchen kein XML-Schema” ist richtig. Die Aussage “Wir brauchen kein Schema” ist falsch. Irgendeine Festlegung muss es geben und man sollte sich sehr genau überlegen ob es dann nicht besser wäre einen öffentlich dokumentierten, formal eindeutigen Standard zu nutzen als auf verschwommene Klartexte zurückzugreifen.

Fazit

Auf die Frage Standard oder Eigenentwicklung kann es keine abschließende Antwort geben. Es ist daher unbedingt notwendig eine ernstgemeinte, ehrliche Analyse vorzunehmen was man von seiner Lösung erwartet und welche Komplexität in dem Artefakt steckt welches gekauft oder entwickelt werden soll.