Vorlagenbasierte Entwicklung bei SaaS & Cloud Service Integration

Kann die Integration von SaaS und interner IT-Landschaft mit vorkonfigurierten und template-gestützten Lösungen vereinfacht werden? Nach diversen Gesprächen und Vorträgen zu diesem Themenbereich und ersten praktischen Erfahrungen eine Einschätzung zum Reifegrad solcher on-/off-premise Integrationslösungen.

Als Integrationsspezialist mit einer Historie in der Vereinheitlichung von Integrationsanforderungen auf methodischer Ebene sehen wir derzeit verschiedene Ansätze die Integrationsarbeit zu optimieren. Neben den technologischen Patterns und Templates der letzten Jahre, welche verschiedene Hersteller nur mäßig unterstützen, freuen wir uns über die nun folgende Umsetzung in die Toolings der etablierten Integrationswerkzeuge. Sicher ein sehr wertvoller Schritt! Aber greift das nicht für einfachere on-/off-premise Integrationen zu kurz?

Die Unterstützung für Patterns in Integrationswerkzeugen (wie z.B. beim WebSphere Message Broker oder Enterprise Service Bus – siehe Blogeintrag) kann die konsistente Entwicklung komplexer Integrationsszenarien verbessern. Damit wir die gewünschte Qualität mit erhöhter Produktivität erzeugt. Jedoch ist die Integration von Software as a Service Lösungen häufig weniger komplex als bei solchen klassischen ESB Anforderungen.

Weiterhin wird von weniger Praxis erfahrenen Entwicklern gerne ein Architektur Overkill verfolgt. Was meine ich damit? Jede unwahrscheinliche Variante in den angestrebten Applikationen soll mit einer „schönen“ SW Architektur abgedeckt werden. Die Folge ist ein sehr langer Entwicklungszyklus mit dem Ergebnis einer zwar nahezu perfekten, jedoch schwer zu durchschauenden Lösung. Dies bedingt nachfolgend entsprechend längere Einarbeitungs- und Projektzeiten.

Aus der Komplexität der klassischen EAI Tools und dem nachvollziehbarem Wunsch nach Perfektion, ergeben sich in Kombination dieser beiden Gegebenheiten mannigfache Herausforderungen.

Nicht das ich beides ablehne – davon bin ich weit, weit entfernt – nur man sollte immer die Angemessenheit eines Lösungsansatzes zur Problemstellung im Auge behalten. Wenn notwendig – und nur dann – sollten hochgradig komplexe Lösungen erstellt werden.

Also stellt sich im Bereich von Cloud Service oder SaaS Integration die Frage – was ist angemessen und bis zu welchen Punkt kann eine Lösung vorkonfiguriert werden? Dabei sind natürlich die Rahmenparameter wesentlich:

• welcher Prozess und welche Anmerkungen sollen mit welchem IT Personal umgesetzt werden?
• Wie gut sind die Applikationen auf die on-/-off-premise Integration vorbereitet?
• Wie vereinheitlicht und typisiert sind die darunter liegenden Datenmodelle?

Beispielsweise wurde in einem Projektgespäch mit Vertretern von IBM Tivoli recht schnell klar, dass die Benutzerdaten zwischen Identitymanagement Lösungen sehr gut mit deren Directory Integrator zu synchronisieren und zu konvertieren sind. Somit eine zweckgebundene Lösung, welche auch zwischen höchst unterschiedlichen Systemen (wie Dateien, Datenbanken, Verzeichnissen, Nachrichtenwarteschlangen und Web-Services) Verwendung finden kann.

Fest definierte und kaum veränderliche Datenstrukturen für die Geschäftsobjekte schaffen somit die Vorraussetzung für die Paketierung. Gleiches gilt für den so häufig zitierten Fall der CRM Integration – z.B. Salesforce mit SAP oder Microsoft Lösungen. Auch hier liegen mehr oder weniger „statische“ Datenstrukturen vor, welche sich einwandfrei für ein Mapping-Muster eignen. Diese können also auch gut in ein Integrationspaket mit einer ca. 80% Abdeckung vordefiniert werden, welches dann nur noch der restlichen, spezifischen Mappings und Transformationen bedarf.

Sicher bleibt es vom Customizing der Standardanwendungen abhängig welchen Abdeckungsgrad man mit den vorbereiteten Patterns und Templates erreicht. Zum Beispiel hat sich in einem aktuellen SAP-Integrationsprojekt gezeigt, dass eigentlich wenig an den Standard SAP-Objekten geändert wurde. Eher bestehen nur Erweiterungen an diesen Objekten, welche auf eine individuelle Struktur eines Message Queuing Endpunkts transformiert werden.

Bei heute noch wenig stabilen Servicelösungen im SaaS Deploymentmodell und eventuell sehr stark „verbogenen“ Standardprodukten oder mit hoher Individualität eigenentwickelten Applikationen können solche paketierten Integrationslösungen eher seltener helfen. Gleiches gilt bei sehr vielen zu integrierenden Lösungen mit erwünschter hoher Wiederverwendungsrate von Services (so sie denn zu realisieren ist). Hier spielen die etablierten EAI/ESB Lösungen ihre Stärke aus.

Bei den Gegebenheiten der etablierten SaaS Lösungen und Standard Unternehmensanwendungen kann jedoch wie oben besprochen sehr gut über vorgefertigte Patterns und Templates die konkrete Applikationsintegration vereinfacht, beschleunigt und somit kostenreduziert realisiert werden. Somit sehen wir mit diesen ersten Erfahrungen der weiteren Integration der Cast Iron Systems OmniConnect Lösungen in das IBM WebSphere Portfolio positiv entgegen.