Die Anfänge der Integration verschiedene Anwendungen in einem Unternehmen reichen zurück zu sehr einfachen Architekturen. Wenn es nur darum geht, wenige Anwendungen zu verbinden, dann funktioniert das natürlich auch ohne komplexe SOA-Produkte. Eine Integration ohne entsprechende Produkte führt meistens zu Peer-to-Peer- oder Client-Server-Architekturen.
Peer-to-Peer-Architekturen
Peer-to-Peer-Architekturen sind der einfachste Weg zur Integration. Anwendungen werden hierbei direkt miteinander verbunden (Siehe Bild: Peer-to-Peer-Architektur). Vorteil des Peer-to-Peer-Verfahrens ist, dass die Integrationsmethode einfach zu erlernen ist. Die Integration liegt vollkommen in der Kontrolle des Entwicklungsteams, das zur Integration spezielle Adapter für andere Systeme entwickeln muss. In der Regel ist hier die Philosophie, dass das Nachbarsystem möglichst nicht verändert wird. Stattdessen liegt im Adapter die gesamte Integrationsarbeit. Ein anderer Weg ist es, dass das Nachbarsystem für die neuen Anforderungen angepasst und danach ein spezieller Adapter geschrieben wird.
Foto: Steppan
Diese Adapter sind der erste gravierende Nachteil dieser Architektur. Dadurch, dass kein Standardverfahren für die Entwicklung solcher Adapter existiert, besteht die Gefahr, dass die Entwicklungsteams sehr spezielle Lösungen programmieren. Zudem müssen diese Lösungen individuell dokumentiert werden. Ihre Funktion ist daher unter Umständen für Außenstehende nur schwer zu verstehen und zu warten. Ein weiterer Nachteil von Peer-to-Peer-Architekturen ist die schlechte Wiederverwendung. Lösungen, die innerhalb der Anwendungen existieren, sind meistens so speziell auf das System zugeschnitten, dass sie anderweitig kaum einsetzbar sind.
Problematisch ist auch, dass mit solchen Architekturen die Gefahr eines Spaghetti-Designs der Unternehmenslandschaft steigt. Ein Wildwuchs von Verbindungen schafft sehr viele Abhängigkeiten. Erfahrungsgemäß sind diese Abhängigkeiten schlecht dokumentiert. Existiert kein Bebauungsplan (siehe Kasten "Glossar"), müssen die Abhängigkeiten durch aufwändige Revisionsprojekte ermittelt werden, um die Risiken zu minimieren. Migrationsprojekte sind in solchen Architekturen wegen der vielen unbekannten Abhängigkeiten aufwendig und teuer. Da man meistens nicht alle Abhängigkeiten feststellen kann, sind solche Projekte zudem riskant. Und nicht zuletzt skalieren solche Architekturen sehr schlecht, weswegen sie meistens durch eine Client-Server-Architektur abgelöst werden.