Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010

Transkript

1 Architekturentscheidungen für große langlebige Softwaresysteme: Vendor-Lock-in- und Netz-Effekte Menschen beraten Menschen beraten BTC zeigt Wege auf - Sie entscheiden BTC zeigt Wege auf - Sie entscheiden Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe Bad Honnef, 3. Mai 2010

2 Problematik Typische Architekturentscheidung auf hoher Ebene: Individualentwicklung einer Komponente vs. Nutzung einer externen Standardkomponente 2 Dabei zu beachten: Negative Vendor-Lock-in-Effekte Positive Netz-Effekte Benötigt werden Strategien, die für ein Gesamtsystem die negativen Effekte minimieren und die positiven Effekte maximieren

3 Vendor-Lock-in- und Netz-Effekte 3 Vendor-Lock-in-Effekte Nachteile, die aus der Nutzung eines Produkts eines Anbieters entstehen Bindung an diesen Anbieter Kosten für den Wechsel des Anbieters Zwang zur Nutzung weiterer Produkte Nachteile steigen mit Lebensdauer eines Softwaresystems Netz-Effekte Vorteile, die für einen Nutzer eines Produkts durch weitere Nutzer entstehen Skaleneffekte bzgl. Verteilung der Entwicklungskosten Interoperabilität bzw. Möglichkeit zum Datenaustausch Möglichkeit zur Nutzung weiterer Produkte, z.b. Werkzeuge

4 Langlebige Softwaresysteme Langlebig = >10 Jahre, >20 Jahre? 4 Welche Softwaresysteme sind langlebig bzw. welche sind kurzlebig? Wie lang lebt ein Softwaresystem? Komponenten des Systems werden ausgetauscht Architektur ändert sich schrittweise Nach einiger Zeit ist eventuell keine Original-Komponente mehr Teil des Systems Aber insgesamt gibt es eine Kontinuität in der Entwicklung Von einem Schritt zum nächsten bleibt ein wesentlicher Teil des Systems bestehen

5 Langlebigkeit von Softwaresystemen: Beispiele Weiß man im Voraus, ob ein Softwaresystem langlebig ist? Manchmal ja, manchmal nein. Aber wenn man es weiß, sollte dies beim Entwurf berücksichtigt werden. 5 Beispiele: System zur Verwaltung der Anträge auf Abwrackprämie Vertragsverwaltung für Lebensversicherungsverträge Netzleitsystem zur Überwachung und Steuerung von Energieversorgungsnetzen BTC PRINS Netzleitsystem für Energieversorgungsnetze Ca. 4 Millionen Zeilen C/C++-Code 30jährige Entwicklungsgeschichte

6 Softwarearchitektur 6 Softwarearchitektur ist eine Folge von Architekturentscheidungen Zeitlich geordnet Untereinander abhängig Entscheidungen unter Unsicherheit Individuell für das entwickelte System

7 Architekturentscheidungen: Beispiele 7 Höchste Ebene Festlegung eines Architekturstils Zerlegung des Systems in fachliche Komponenten Identifikation benötigter technischer Komponenten Festlegung erlaubter Abhängigkeiten von Komponenten Ausgestaltung der von einer Komponente angebotenen Schnittstelle Hohe Ebene Entwicklung einer Individualkomponente vs. Nutzung einer Standardkomponente Auswahl übergreifend einzusetzender Entwurfsmuster Mittlere Ebene Anwendung eines Entwurfsmuster in bestimmten Kontext

8 Individualkomponenten vs. Standardkomponenten Nachdem bei der Zerlegung des Systems ein Komponententyp identifiziert wurde, stellt sich die Frage, ob hierfür eine Individualkomponente entwickelt oder eine Standardkomponente genutzt wird. 8 Typische Arten von Standardkomponenten sind: Betriebssystem Programmiersprache Datenbank- Management- System GUI-Framework Unit-Test- Framework

9 Nutzung von Standardkomponenten Ist das eine Frage der Anforderungen? Ja, aber nicht nur! Auch wenn die Standardkomponente zum Entscheidungszeitpunkt perfekt geeignet ist, geht man eine Abhängigkeit vom Anbieter ein. 9 Ist das eine Frage des Abhängigkeitsmanagements? Ja, aber nicht nur! Die Weiterentwicklung einer Standardkomponente folgt nicht den Anforderungen eines einsetzenden Systems. Verwendung einer Standardkomponente fügt daher langfristig Risiken hinzu. Besonders bei Standardkomponente von externem Anbieter Im Folgenden: genauerer Blick auf diese Risiken

10 Ursachen der langfristigen Risiken aus der Abhängigkeit von externen Standardkomponenten 10 Externe Ursachen Konkurs des Anbieters o.ä. Entscheidungen des Anbieters Einstellung der Wartung Fokussierung eines anderen Zielmarkts Beendigung der Unterstützung einer technischen Plattform Beendigung der Unterstützung eines Neben-Anwendungsfalls Zwang zum Umstieg auf neue Version Änderung von Lizenzbestimmungen und -preisen Entscheidungen des Kunden Änderung der technischen Plattform Änderung der funktionalen oder nicht-funktionalen Anforderungen

11 Nutzung von Standardkomponenten: Extremstrategien Die Nutzung von Standardkomponenten ist auf wenige stabile Basiskomponenten zu beschränken. z.b. wenn das Vertrauen in die potenziellen Anbieter gering ist. Aber Vorsicht: Nutzen aus Netzeffekten wird minimiert. Gefahr, dass Rad neu erfunden wird, und Fehler anderer wiederholt werden. Großer Wartungsaufwand. Für möglichst viele Aufgaben sollen externe Standardkomponenten genutzt werden. Dadurch soll der Individualanteil am System minimiert werden. wenn Risiko aus Vendor-Lock-in-Effekten als gering eingeschätzt wird. Der Nutzen aus Netzeffekten kann damit maximiert werden. Aber Vorsicht: Aufwand für Anpassung/Komposition? Gefahr des Architectural Mismatch. 11 Benötigt werden Strategien zur Minimierung der Vendor-Lock-in-Effekte und Maximierung der Netz-Effekte!

12 Abstraktionsschichten Beispiel: Für ein System soll eine MS SQL Server Datenbank angebunden werden Oracle Database wird als mögliche zukünftige Alternative betrachtet Es soll eine Datenbank-Abstraktionsschicht entworfen werden 12 Eigenschaften einer Abstraktionsschicht Definiert Schnittstelle, die unabhängig von nutzender und anbietender Komponente ist Stellt Austauschbarkeit der Standardkomponenten sicher Client 1 Client 2 <<uses>> <<uses>> Abstract Interface <<impl.>> <<impl.>> SQL Server Provider Oracle Provider <<uses>> <<uses>> SQL Server Oracle

13 Varianten der Definition einer Abstraktionsschicht Variante 1: Abstraktionsschicht bietet nur Basisschnittstelle an Schnittmenge aus MS SQL Server und Oracle Database Funktionalitäten Ermöglicht einfache Implementierung der Provider 13 Variante 1a: Abstraktionsschicht ist undurchlässig geringer Nutzen: Client muss eventuell Funktionalität nachbilden, die MS SQL Server anbietet Variante 1b: Abstraktionsschicht ist durchlässig Abhängigkeit bleibt bestehen, evtl. kann ihre Invasivität reduziert werden Variante 2: Abstraktionsschicht bietet eine erweiterte Schnittstelle an Wer bildet dann die fehlenden Funktionalitäten nach? Client, Provider, generisches Zwischenstück? Es gibt keine eindeutig beste Alternative!

14 Fazit & Ausblick Betrachtung typischer Architekturentscheidungen auf hoher Ebene: Individualentwicklung einer Komponente vs. Nutzung einer externen Standardkomponente Langfristig entstehen aus der Nutzung externer Standardkomponenten Risiken Betrachtung im Kontext anderer Architekturentscheidungen 14 Strategien, die für ein Gesamtsystem die Vendor-Lock-in-Effekte minimieren und die Netz-Effekte maximieren Einfluss von Abstraktionsschichten, Open-Source-Software, Wie bewertet man solche Strategien? Empirisch: Aufwändig, eventuell mit historischen Daten Theoretisch: Real-Optionen-Ansatz Entwicklung von Handlungsempfehlungen

15 15 Danke für Ihre Aufmerksamkeit!

16 Quellen Breivold et al H. Breivold, I. Crnkovic, P. Eriksson: Evaluating Software Evolvability; in: Proc. of SERPS 07, Chalmers University of Technology, , Eisenführ u. Weber 2003 F. Eisenführ, M. Weber: Rationales Entscheiden, Springer, Hasselbring 2006 W. Hasselbring: Software-Architektur (Aktuelles Schlagwort); in: Informatik-Spektrum 29(1):48-52, Siedersleben 2004 J. Siedersleben: Moderne Software-Architektur, d.punkt,