Schlagwort: Time-to-Market

Die WICSA 2015 fand vom 04. bis 07. Mai zusammen mit der CompArch in Montreal statt.

Das gesamte Programm war sehr abwechslungsreich und beleuchtete viele Facetten rund um Softwarearchitektur. Das ausgerufene Konferenzthema war „Architecting in Context“, insgesamt gab es aber keine dominierenden thematischen Schwerpunkte. In meinem Bericht greife ich deshalb einfach Themen und Vorträge auf, die mich am meisten angesprochen haben.

Clemens Szyperski hielt am Auftakttag im Rahmen der WCOP eine Keynote „Maintaining composure: The long journey along the path of compositional software engineering”. Sein Hauptfokus waren kompositionale Aspekte in der Softwareentwicklung, von der Komposition von Funktionen über Komponenten bis hin zu Services. Eine interessante Beobachtung dabei ist, dass Komposition in der Softwareentwicklung immer nur ein Einbinden von ausgelagertem Code ist, wenn auch auf unterschiedlichen Größenordnungen. Das steht im Gegensatz zu Komposition z.B. im chemischen Bereich, wo tatsächlich andere Verbindungen entstehen können durch chemische Reaktionen. Das einzige Beispiel aus der Softwareentwicklung, das etwas anders ist, ist die Aspektorientierung. Die hat Clemens aber nochmal besonders im Hinblick auf Komposition hervorgehoben: Sie funktioniert zuverlässig eigentlich nur, wenn man nur einen Aspekt einwebt, und somit keine Interaktion zwischen Aspekten hat. Somit ist die Komponierbarkeit „etwas eingeschränkt“.

Clemens hatte noch einen weiteren sehr interessanten Aspekt in seiner Keynote: Er verglich das Architekturdesign mit „negativem Zeichnen“ („negative space drawing“). Dabei zeichnet man nicht das eigentliche Objekt, sondern alles außenrum, sodass das Objekt dadurch sichtbar wird. Negatives Zeichnen bewirkt im Gehirn andere Denkprozesse und arbeitet das zu zeichnende Objekt anders heraus. Bezogen auf Softwarearchitektur stellte Clemens heraus, wie ein Softwarearchitekt nicht die konkrete Lösung vorgibt, sondern eher Pfeiler einschlägt, indem er vorgibt, wie gewisse Aspekte auf keinen Fall umzusetzen sind. Ganz im Sinne einer Keynote führte dies zu sehr angeregten Diskussionen, die auch noch am Nachmittag in einer Working Session fortgesetzt wurden. Wir kamen zu dem Schluss, dass der veränderte Blickwinkel auf die Erzeugung von Architekturentscheidungen durchaus nützlich sein kann, dass aber umgekehrt auch viele Fragen offen bleiben, wie z.B. die nach der geeigneten Dokumentation von so getroffenen Architekturentscheidungen. Wie bei so vielen Analogien zu Softwarearchitektur hatten wir am Schluss den Eindruck, dass sie in einigen Bereichen sehr nützlich sein kann, aber doch auch viele Limitierungen hat.

Len Bass hielt eine Keynote “Design for Deployment”. Das dahinterstehende Ziel ist eine schnelle Time-to-Market für neue Features und damit verbunden die Fähigkeit zu schnellen Releases. Len schloss damit an die Themen „DevOps und Microservices“ der SATURN an. Er arbeitete heraus, dass für eine hohe Releasehäufigkeit die Abstimmung zwischen Teams reduziert werden muss. Dazu arbeiten Teams eigenverantwortlich an einem klar definierten Systemteil (Microservice) und interagieren mit den Systemteilen der anderen Teams über klar definierte Schnittstellen. Das stellt eine sehr konsequente Umsetzung von Conway’s Law dar. Über einen hohen Automatisierungsgrad im Test und die integrierte Verantwortung für Entwicklung und Betrieb (DevOps) kann dann die hohe Releasehäufigkeit erreicht werden. Len stellte weitere Implikationen für die Architektur heraus, z.B. Aspekte wie Zustandslosigkeit von Services, um sie möglichst gut skalieren zu können. Ein zentrales Thema in der Keynote war auch das Upgrade von Services auf neuere Versionen und was das im Zusammenspiel mit anderen Services und für die Realisierung von neuen Features bedeutet. Len stellte dafür Strategien vor und erläuterte die Rolle von Feature Toggles, mit denen ein Feature global oder selektiv freigeschaltet werden kann, wenn das Deployment abgeschlossen ist. Auch die Nutzung von Feature Toggles für sogenannte Canary Tests (bei denen neue Features mit einer ausgewählten Submenge der Gesamtnutzer vorsichtig getestet werden) arbeitete Len heraus. Len hielt wie immer einen Vortrag von hoher praktischer Relevanz, in dem er sowohl die dahinterliegende Motivation als auch die Architekturkonzepte und konkrete Umsetzungstechnologien klar herausarbeitete.

Jan Bosch hielt eine mitreißende Keynote „From Opinions to Facts: Building Products Customers Actually Use”. Wer Jan schon einmal auf der Bühne erlebt hat weiß, dass seine Vorträge extrem unterhaltsam und mit sehr vielen konkreten Beispielen illustriert sind. Seine Kernaussagen waren

• „Kunden wissen nicht, was sie wollen. Deshalb ist es nötig, schnell Experimente machen zu können.“ Dazu zitierte er natürlich Henry Ford: „If I had asked people what they wanted, they would have said faster horses.”
• „Eine schnelle Time-to-Market ist absolut essentiell und ein entscheidender Wettbewerbsvorteil, und unabdingbar für schnelle Experimente.“

Jan illustrierte sowohl den Wert von schneller Time-to-Market als auch methodische und architekturelle Aspekte, um sie zu erreichen. Architekturell schließt sich das an die Keynote von Len Bass an und greift DevOps und Microservices Ideen auf. Er sieht Architekten als Coaches direkt in den Entwicklungsteams, die meist auch noch direkt mitentwickeln. Jan betonte, dass wirtschaftlich eine schnelle Time-to-Market auf jeden Fall einen höheren Wert hat als Geld einzusparen durch eine höhere Produktivität. Er beschreibt eine 5-stufige „stairway to heaven“:

• Traditionelle Entwicklung
• Agile Entwicklung
• Continuous Integration
• Continuous Delivery
• R&D als ein Innovationssystem mit schnellen Experimenten

Um Kunden genau die Produkte und Features liefern zu können, die sie brauchen und nutzen, läuft es auf das schnelle Experimentieren heraus: der Produktanbieter beobachtet die Nutzer bei der Produktnutzung und fährt auch direkte Vergleiche von Systemvariationen (A/B-Tests). Dies ist nur möglich, wenn der Produktanbieter neue Features und Variationen sehr schnell releasen kann. Um dies zu erreichen müssen strategische, methodische, organisatorische, und architekturelle Aspekte der Entwicklung und des Betriebs optimal aufeinander abgestimmt werden. Jan überraschte in seiner Keynote damit, dass er mit seiner Gruppe aktuell daran arbeitet, diese Art des schnellen Experimentierens nicht nur für Internetfirmen nutzbar zu machen sondern auch für eingebettete Systeme wie Autos, wo er mit Volvo kollaboriert.

Ian Gorton stellte eine sehr interessante Arbeit zum Thema Architekturwissen und Wissensmanagement vor: Während Technologien häufig sehr ausführlich in Bezug auf ihre Benutzung beschrieben werden, findet man fast nie eine gute Beschreibung der architekturellen Implikationen. Ian stellte dazu am Beispiel von aktuellen Big Data Technologien vor, wie solches Wissen aufbereitet und bereitgestellt werden kann. Dazu wurde am SEI eine Erweiterung zu MediaWiki erstellt, was Konzepte wie Architekturtreiber und Architekturentscheidungen aufgreift und im Sinne strukturierter Daten erfassbar macht. Das Wiki führt durch die Erfassung und Dokumentation architekturrelevanter Aspekte und macht das Auffinden leicht. Initial gefüllt ist das Wiki mit dem Namen QuABaseBD mit Architekturwissen zu Big Data Technologien. Nach wie vor ist das Erstellen solchen Wissens mit sehr viel Aufwand verbunden und es ist schwierig, die richtige Abstraktionsebene zu finden, um im konkreten Nutzungsfall dem Architekten die richtigen Antworten zu liefern. Es ist definitiv noch einiges an Forschung nötig, um die richtige Art der Informationserfassung, -aufbereitung, -suche und –verwendung von Architekturwissen zu bestimmen.

Eltjo Poort hat untersucht, inwiefern sich die Einbeziehung von Architekten in der Projektanbahnungsphase auswirken kann. Er arbeitet für die niederländische Firma CGI, die viele Softwareprojekte mit Festpreisangeboten anbietet und deshalb auf eine präzise Kostenschätzung angewiesen ist. Eltjo stellte eine Methode vor, in der Projektmanager, Kostenschätzungsexperten und Architekten zusammenarbeiten, um zu einer Kostenschätzung zu kommen, die möglichst präzise ist. Dazu wird eine erste grobe architekturelle Zerlegung des Systems vorgenommen, um mit diesem Wissen bessere Schätzungen machen zu können. Dazu konnte er auch aus einer wissenschaftlichen Untersuchung Zahlen präsentieren: In untersuchten Projekten kam es zu deutlich weniger Budgetüberziehungen (3% statt 22%) und weniger Zeitüberziehungen (8% statt 48%) wenn entsprechende Architekturarbeiten in der Kostenschätzung durchgeführt wurden.

Ich hielt meinen Vortrag als Plädoyer dafür, Daten mehr Aufmerksamkeit beim Architekturdesign zu widmen. Das mag in Zeiten von Big Data erst mal grotesk erscheinen. Betrachtet man aber Daten in einer Architekturbeschreibung, so beschränkt sich das meist auf einen Datenmanagement-Layer mit Datenbanken und ein Datenmodell. Das wird dem Einfluss von Daten auf das Architekturdesign und die Erreichung von Qualitätseigenschaften nicht annähernd gerecht. Insbesondere der Einfluss auf User Experience und Performance und natürlich auf Security ist enorm. Um die richtigen Daten zum richtigen Zeitpunkt am richtigen Ort zu haben, müssen Architekten sich bedeutend mehr Gedanken machen als eine Datenbank auszuwählen und ein Datenmodell zu designen. Am Beispiel eines Projekts von John Deere und Fraunhofer IESE haben wir gezeigt, wie vielfältig die Anforderungen und geforderten Qualitätseigenschaften sich um Daten drehen, und welche Architekturentscheidungen dafür getroffen wurden. Dabei ging es um Themen wie Inter-App-Kommunikation, Offline-Fähigkeit, Mandantenfähigkeit, Mehrsprachigkeit uvm. Im Anschluss gab es in der Working Session eine angeregte Diskussion zum Thema, die eine breite Mehrheit dafür fand, dass Daten wirklich mehr Aufmerksamkeit brauchen (und wir reden hier nicht davon, dass man den derzeit allgegenwärtigen Einsatz von Big Data Technologien fordert: dann wird nämlich oft genau der gleiche Fehler gemacht ;-).

Ian Gorton, Jean-Guy Schneider, Len Bass, Patricia Lago und Ralf Reussner diskutierten in einem teils humoristisch und teils ernst geführten Panel „Future Directions for Software Architecture Research”. Aus dieser Diskussion gebe ich hier nur einige Ausschnitte wieder.

Die Forschung zu Softwarearchitektur soll …

• … endlich die großen Probleme angehen und nicht nur die „low-hanging fruits“ ernten (Ian Gorton)
• … sich mehr um aktuelle innovative Themen kümmern, wie z.B. die „16 Dinge“ von Andreessen Horowitz (von Len Bass ins Spiel gebracht mit einer Vorauswahl)
  

  „16 Dinge“ von Andreessen und Horowitz (http://a16z.com/2015/01/22/16-things/)

• … sich noch mehr um verschiedene Sichten auf Softwaresysteme kümmern und wie diese konsistent gehalten werden können (Ralf Reussner)
• … sich mehr damit auseinandersetzen, was die kognitiven Limitierungen von Menschen im Engineering sind und wie Methoden und Tools deshalb gestaltet werden müssen (Ralf Reussner)
• … sich mehr um das Thema Skalierbarkeit kümmern, insbesondere vor dem Hintergrund wie große skalierbare Systeme getestet werden können (Jean-Guy Schneider)
• … sich mehr um die Integration in den gesamten Entwicklungsprozess und den Lebenszyklus von Systemen kümmern
• … mehr zusammenarbeiten und auch fokussieren, um von zu vielen isolierten Forschungsinseln wegzukommen
• … durch Benchmarks und Vergleichbarkeit von Methoden sich gegenseitig zu neuen Ideen anstacheln
• … gemeinsam Architekturwissen sammeln, aufbereiten und der Praxis zugänglich machen, um mehr Einfluss zu gewinnen

Die WICSA 2015 war eine sehr kurzweilige Veranstaltung mit vielen interessanten Denkanstößen und Erkenntnissen. Der Modus einer „Working Conference“, das heißt mit Impulsvorträgen und dann längerer Diskussion, führte zu sehr angeregten und tiefen Diskussionen, manchmal sogar zu Grundsatzdiskussionen des Software Engineering. Umso wichtiger ist aber auch die aktive Teilnahme des Publikums, das sich heute manchmal eher hinter dem Laptop versteckt als aufmerksam zuzuhören. Einer der Session Chairs hat vorgemacht, wie das umgangen werden kann: Er hat alle Zuhörer nach vorne geholt und Laptops für unerwünscht erklärt – und damit die diskussionsreichste Session der Konferenz ermöglicht.

2016 wird die WICSA wieder zusammen mit der CompArch stattfinden, dann in Venedig. Ich freue mich schon drauf!