1. July 2007, 21:10, by Silvan Mühlemann

Applikationen von Drittanbietern integrieren.

IntegrationBei tilllate ist momentan eine Diskussion zum Thema “Integration von externen Applikationen auf www.tilllate.com” im Gange. Dieser Artikel beleuchtet Kosten und Risiken einer solchen Integration.

Beispiel: Anstatt ein Forum selbst zu entwickeln, soll FUDForum oder phpBB genommen werden und auf tilllate.com integriert werden. Damit sollen Entwicklungskosten und -zeit gespart werden. Warum etwas, was es auf dem Markt schon gibt, selbst entwickeln?

Die These

Die Integration von externen Applikationen ist nur rentabel, wenn folgende Bedingungen gegeben sind:

  • wenig Abhängigkeiten
  • externe Applikation stellt Schnittstellen bereit, um die Abhängigkeiten zu implementieren

Gehen wir aber in die Tiefe:

Die Integrationskosten sind schuld!

Auf den ersten Blick eine verlockende Idee. Wenn die Integrationskosten nicht wären.

Im Beispiel “Forum für tilllate.com” erscheinen sie mir höher als die Kosten, wenn man sowas selbst entwickeln würde.

Was sind Integrationskosten? – Diese Kosten sind jene Kosten, welche entstehen, damit man die Applikation optimal integriert hat.

Was heisst “optimal integriert”?

Optimal integriert heisst, dass der Benutzer nicht merkt, dass er mit einer Fremdapplikation arbeitet. Das heisst:

  1. Er muss sich über tilllate einloggen können, ins Forum gehen und dort gleich seine Beiträge posten können. – Integration von Authentifizierung und Berechtigungen
  2. Das Design muss gleich aussehen.
  3. Die Benutzerführung muss gleich sein. Beispiel: Auf tilllate.com, wenn man auf den Nickname des Benutzers klickt, kommt man direkt auf die Profilseite des Benutzers.
  4. Auf der Profilseite des Benutzers sollen seine letzen Posts angezeigt werden: Integration von bestimmten Subviews des Forums in die Stamm-Applikation

Wie erreicht man optimale Integration?

  1. Authentifizierung und Berechtigungen: Es muss eine Schnittstelle definiert sein, wie Authentifizierungs- und Berechtigungsinformationen übertragen werden zwischen den beiden Applikationen. Single-Login kann mit LDAP erreicht werden. Doch wie kriegen wir es hin, dass die externe Applikation die Informationen über die aktuelle Session erhält? Hier exisitiert kein Protokoll.
  2. Design: Mit einem geeigneten CSS kann man die externe Applikation annähern an die eigene Applikation. Doch auch mit CSS2.1 lässt sich Darstellung und Inhalt noch nicht komplett voneinander trennen (Glaubst Du nicht? Man schaue sich mal digg.com oder google.com ohne CSS an und finde im HTML-Code Elemente, welche eher zur Darstellung als zum Inhalt gehören :-))
  3. Benutzerführung, der “Feel”: Dies Bedarf Eingriffe im Sourcecode der externen Applikation. Ausser die externe Applikation stellt eine Schnittstelle bereit, um dies zu Customzien
  4. Integration von bestimmten Subviews des Forums in die Stamm-Applikation: Auch hier ist eine Schnittstelle notwendig, um die Daten abzurufen

Schnittstellen sind der Schlüssel

Man stellt fest: Die optimale Integration erreicht man

  1. durch die Anpassung der externen Applikation, damit sie sich gleich wie die eigene Applikation verhält,
  2. durch Anbindung der externen Applikation an die eigene Applikation über eine Schnittstelle. Existiert diese nicht, so muss sie gemäss Punkt 1 zuerst entwickelt werden.

Anpassung der externen Applikation?

Bei OpenSource-Programmen läss sich die Anpassung der externen Applikation zwar erreichen. Doch mit dem Preis, dass sich diese nicht mehr upgraden lässt. Ausserdem ist die Wartung vom fremdem Programmcode mit Aufwand (Einarbeitunsgzeit) und Unsicherheiten (kein vollständiges Verständnis des Codes) verbunden.

Verzichtet man auf Anpassung, bleib die Variante “Schnittstellen verwenden“. Hier ist die Voraussetzung, dass diese Schnittstellen existieren. Im SOA-Fieber ist ein Trend zu mehr Schnittstellen zu beobachten. Meist handelt es sich um Web-Services, welche die Applikation gegen aussen anbietet. SOAP oder UDDI sind die Stichworte.

Doch leider haben die wenigsten OS-Applikationen derartige Schnittstellen, da sie oft als Standalone-Applikationen gedacht sind.

Somit bleibt in diesem Beispiel of die Variante “Selbst entwickeln” übrig, so unökonomisch diese erscheint.

Beispiel Amazon S3 und Facebook

Beispiel 2: Amazon S3. Externe Applikation. Einiges komplexer als ein Forum. Doch die Schnittstelle steht bereit: Einfaches REST-Interface. Abhängigkeiten in Design, Look and Feel, Authentifizierung? Keine.

Hier lohnt sich die Integration des externen Dienstes.

Facebook arbeitet mit tausenden von externen Diensten zusammen. Den Facebook applications. Schlau gelöst: Sie selbst definieren die Schnittstelle. Als REST-Interface. Die Abhängigkeit “Design” elegant mit einem HTML-Subset gelöst, der FBML. Damit passen sich die externen Applikationen ihnen an. Und nicht umgekehrt. Null Integrationskosten.

Die Zukunft

Applikationen werden offener werden. Es werden sich neue Protokolle durchsetzen. Die Integration von externen Applikationen wird einfacher werden.

Um Eigenentwicklungen für Produkte, welche bereits auf dem Markt existieren, wird man wohl nie ganz herumkommen. Die ultimative Schnittstelle wird es nie geben.

Filed under: Management

4 Comments

  1. Super Post! Zustimmende Worte von Clay http://killersoft.com/randomstrings/2006/06/14/stop-writing-loner-applications/ und Matthew http://weierophinney.net/matthew/archives/138-Start-Writing-Embeddable-Applications.html.

    Comment by Maarten Manders — 1. July 2007 @ 21:42

  2. Diese Überlegungen scheinen (wie Maartens Links zeigen) immer wieder aufzutretten.

    Eine vollständige Integration dürfte sich aber nur schwer erreichen lassen. Die Anpassung des Codes ergibt die von dir schon erwähnten Probleme, selbst wenn der Code sehr gut geschrieben wäre (was ja leider nicht immer der Fall ist). Aber auch die Webserviceschnittstelle ist für mich ein Fragezeichen. Während Amazon mit ihrem S3 die Schnittstelle für genau ein Problem (Speichern von Daten) anbietet, müsste eine Forumsoftware eine Schnittstelle für Duzende von Problemen anbieten. Es fragt sich dann ob sich der Aufwand lohnt die Webservices zu verwenden, die einzelnen Komponenten währen wohl so trivial das sich hier sogleich die Eigenimplementation wieder in den Vordergrund drängen würde.

    Comment by Leo Büttiker — 15. July 2007 @ 09:30

  3. Auch ich stehe vor der Integration einer Forensoftware bei einem größeren Projekt. Die Deadline des Projektes ist am 01.01.2008.

    Mir persönlich würde aber nicht in den Sinn kommen, PhpBB in Erwägung zu ziehen. Wieso kam diese Software bei Euch in die engere Wahl?

    In Hinblick auf Eure Userzahl, würde ich eher vBulletin bevorzugen. Schaut man sich an, welche Sicherheitslücken bei PhpBB aufgetreten sind, könnte ich zu PhpBB nicht grade Vertrauen fassen. vBulletin ist dagegen bei massiven Foren schon fast Standard. Was mich auch interessieren würde, ich hoffe Ihr lasst Euch zu einer Antwort hinreissen, wieso benötigt ihr so extrem viele Blades? Oder lasst Ihr im Hintergrund Cinema 4D auf den Blades rendern? :-)

    Comment by Jeanot Bruchmann — 29. August 2007 @ 11:33

  4. Wir haben aus den oben erwähnten Gründen nie eine Forensoftware genauer evaluiert, eine Integration war schlicht und einfach nicht wirtschaftlich für uns. FUDForum oder phpBB dienen im Artikel nur als Beispiel. Wir können dir desshalb auch nicht wirklich weiterhelfen, phpBB stand aber wohl dort weil es eines der verbreitesteten Foren mit einem sehr umfangreichen Funktionsumfang ist (auch wenn es in letzter Zeit leider häufig durch Sicherheitslöcher auf sich aufmerksam gemacht hat).

    Ach ja und unsere Blades, mit denen könnten wir ganz sicher auch nette Videoanimationen rendern. Wir liefern damit aber lieber unsere Webseite aus. Weit über 100 Millionen-Pageviews die aus einer sehr umfangreichen Codebasis aus einer grossen Datenbank erzeugt werden fordern unsere Blades bis auf’s letzte.

    Comment by Leo Büttiker — 5. September 2007 @ 12:48

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

© 2017 tilllate Schweiz AG - Powered by WordPress