#12months12papers #2

Architecture Challenges for Internal Software Ecosystems: A Large-Scale Industry Case Study

Klaus-Benedikt Schultis, Christoph Elsner, Daniel Lohmann

Jetzt könnten wir alle denken, bei Informatik und Software ginge es nur um Sourcecode, Programmiersprachen und wie ich jetzt die Threadkommunikation realisiere. Falsch gedacht. Ein großes Problem bei Softwareprojektion ist das Management. Aufgaben richtig zu verteilen und die Anwendung effizient zu erstellen – also wiederverwendbar, modular und trotzdem gut programmiert – ist ein nicht zu verachtender Teil des Softwareentwicklungsprozesses. Das dachten auch die Autoren vom zweiten Artikel meiner Reihe #12months12papers. Sie widmen sich diesen Problemen. Und zwar im Speziellen bei Software-Ökosystemen.

Ein Software-Ökosystem (engl. software ecosystem) beschreibt das Zusammenspiel zwischen Organisationen und Unternehmen auf einem geteilten Markt für Softwareentwicklung und Webservices.
(wikipedia.de, Software-Ökosystem)

In anderen Worten, ein Unternehmen entwickelt eine Software und bietet anderen Organisationen Funktionalität oder Quellcode an. Ein gutes Beispiel ist Apple mit iOS das sie als Plattform entwickeln, aber unabhängigen Entwicklern als Basis für Apps zur Verfügung stellen. Wenn jetzt ein solches Software-Ökosystem geplant, erstellt und programmiert werden, ist einiges zu beachten bzw. es ist gut, einiges im Voraus zu wissen. Die Autoren haben sich in dem Text speziell auf Kollaborationsmodelle und Architekturherausforderungen bezogen. Und zwar haben sie erstere identifiziert und letztere im Bezug auf die Modelle analysiert. Hierzu haben sie viele Stunden Interviews mit verantwortlichen Menschen aus zwei großen Projektion bei Siemens geführt.

Kollaborationsmodelle

Die identifizierten bzw. genannten Akteure bei den Kollaborationsmodellen sind sehr abstrakt gehalten und sind wie folgt definiert:

  • ISECO:
    Internal Software Ecosystem. Dezentrale Topologie von mehreren verschiedenen Akteuren mit unterschiedlichen Zielen, Einflüssen und Organisationsstrukturen.
  • Keystone:
    Anbieter bzw. Entwickler der Plattform (vgl. Apple mit iOS).
  • Core Clients:
    Ursprünglich geplante Nutzer der Plattform.
  • Consumer Client:
    Nutzer, deren Anwendungsfall eigentlich nicht vorgesehen war, die aber die Plattform im Ganzen nutzen. Sie sind locker mit dem Keystone verbunden.
  • Extended Core Client:
    Nutzen nur einen Teil der Plattform, diesen aber sehr stark und sind eng mit dem Keystone verbunden.

Anhand dieser Akteure und den Strukturen in den beiden analysierten Projekten haben die Autoren dann die folgenden Kollaborationsmodelle definiert bzw. extrahiert:

  1. Product Lifecycle Management (PLE) for ISECOs
    Keystone stellt Plattform bereit und ist auf Core Clients fixiert. Andere Akteure spielen keine Rolle bzw. haben keinen Einfluss auf den Entwicklungsprozess und zukünftige Features.
  2. Platform Reuse for ISECOs
    Hier kommen, im Gegensatz zu 1., noch die Consumer Clients hinzu. Diese nutzen die Plattform, haben aber weniger Einfluss im Entwicklungsprozess.
  3. Decoupled Product Lifecycle Management for ISECOs
    Wenn sich herausstellt, dass die Plattform auch für andere Unternehmensbereiche oder Kunden signifikant wichtig und gewinnbringend ist, können Extended Core Clients mit in das Kollaborationsmodell mit einbezogen werden: Sie haben stärkeren Einfluss, da sie die Plattform (oder Teile) stark nutzen.

Anhand dieser drei Modell wurden dann die Einflussfaktoren bzgl. der Organisationsstruktur, des Prozessmanagements, der Architektur und im Management klassifiziert. Im Artikel ist eine schöne Tabelle die das erläutert.

Architekturherausforderungen

Die Architekturherausforderungen die sich während den Interviews ergeben haben sind im Folgenden aufgelistet. Natürlich sind das nicht alle, aber durchaus gute Punkte, die beim Entwickeln eines Softwareökosystems beachtet oder wenigstens kurz durchdacht werden sollten.

A. Platform Opennes Dilemma

Wann öffne ich die Plattform für anderen Entwickler? Zu früh bedeutet das externe Menschen mit krassen Änderungen, Bugs und halbfertigen Features leben müssen, aber eben auch früh Einfluss auf die Entwicklung nehmen können. Zu spät stellt Entwickler und Entwicklerinnen vor vollendete Tatsachen. Diese funktionieren dann aber eben auch.

B. Technical Integration

Was muss alles getan werden, um die Integration von externen Anwendungen, also Anwendungen von der Kunden, so einfach und angenehm wie möglich zu machen? Und wie stark soll die Integration sein? Das heißt, wie abstrakt sollen die Funktionen sein, die von der Plattform angeboten werden? Hier haben die verschiedenen Kunden verschiedene Anforderungen.

C. Independent Platform Developemnt

Wie gehen die Entwickler und Entwicklerinnen der Plattform damit um, dass das Ökosystem sich entwickelt. Bei jedem neuen Release müssen Abhängigkeiten zwischen der Plattform und den Anwendungen der Kunden beachtet werden. Zudem müssen sogenannte breaking changes, also die Wegnahme von Features, angemessen kommuniziert und durchgeführt werden. Alle Entscheidungen müssen so getroffen werden, um eine möglichst gute Evolution des Ökosystems zu ermöglichen.

D. Independent Application Development

Nicht nur die Plattform entwickelt sich am Besten unabhängig. Auch die Clients müssen die Möglichkeit haben, sich unabhängig zu entwickeln. Das schließt die Möglichkeit ein, dass externe Organisationen Funktionen für die Plattform entwickeln. Es ist dann möglich, dass gute Features in die Plattform migriert werden oder die externen Anwendungen bieten sie direkt anderen Anwendungen an.

E. Qualities

Alle Anwendungen des Ökosystems müssen bestimmte Eigenschaften haben. Im Text wird hier zwischen internen und externen unterschieden. Interne Eigenschaften sind z.B. Verständlichkeit oder Lesbarkeit des Quellcodes. Allgemein alle Eigenschaften die die Wartbarkeit betreffen. Die externen Eigenschaften sind z.B. Speicherverbrauch, Zeitverhalten oder Verlässlichkeit. Im perfekten Ökosystem erfüllen alle Softwarebausteine bestimmte Mindestanforderungen.

F. Compliant Software Development

Hier geht es darum, nicht nur die Eigenschaften aller Anwendungen mehr oder weniger konsistent zu halten, sondern auch Entwicklungsstrategien, Maßnahmen und Prozesse unter allen Involvierten zu diskutieren. Zudem geht es darum, wie Verantwortlichkeiten verteilt werden.

Diese Herausforderungen müssen während der Planung, während der Entwicklung und während des Betriebs eines Software-Ökosystems bedacht werden. Der Text gibt dazu gute Fallbeispiele mit nachvollziehbaren Beispielen und Erklärungen. Und das sehr ausführlich. Die Informationen wurden, wie gesagt, aus Interviews mit mehreren hundert Entwicklern und Entwicklerinnen gezogen. Dem Titel nach habe ich eigentlich etwas ganz anderes erwartet, aber letztlich war der Text doch ganz informativ. Und wer sich mit der Entwicklung von einer Plattform beschäftigt, die Services oder Teile des Codes zur Verfügung stellt, kann sich hier gute Inspiration für den Planungsprozess holen.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s