Kategorien
Software-Entwicklung

OOP 2014 – zweiter und dritter Tag

This entry is part 6 of 7 in the series OOP 2014 Report

Ich habe die Notizen und Anmerkungen zu den Vorträgen, die ich an meinem zweiten Tag auf der OOP 2014 besucht habe, bereits in eigenen Blog-Posts verarbeitet:

  1. Software-Evolution mit aim42 – Architecture Improvement Method
  2. How to improve Estimates for Software: The #NoEstimates view
  3. Imposing Rule-Based Architecture on Legacy Systems
  4. Gehirnwäsche für Führungskräfte

Zu den Vorträgen am dritten Tag:

Value Validated Architecture: Discover Your Architecture sans BDUF (Steve Holyer)

Steve Hoyler fragt, ob der Build/Measure/Learn Zyklus auch für Architektur funktionieren kann. Er stellt ein Vorgehen vor, dass versucht, die Architektur bzw. Architekturentscheidungen mit business value zu untersetzen.

Der Anfang klang ganz vielversprechend: brainstorming darüber, was überhaupt zur Architektur gehört. Dies erzeugt einen offenen Dialog und ein geteiltes Verständnis der Beteiligten. Er sprach über Constraints vs. Options und die Frage, welche Constraints Commitments und welche Options sind.

Dann verlor sich Steve etwas in seinem Vortrag. Das muss er noch ausbauen. Insofern am Schluß etwas enttäuschend. Folien gibt es online.

Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr (Michael Stal)

Hier ging es vornehmlich um eine Art Ausbildung zum Software-Architekten mit Beispielen von der Firma Siemens, die da anscheinden sehr viel Zeit und Kapital investieren.

Wie sieht der Weg aus?

  1. Profiling: welches Wissen brauche ich?
  2. Reflection: welche Lücken habe ich?
  3. Doing: Lücken schließen

Architecture 201x (Stefan Tilkov)

Mit dem Untertitel „Lessons learned from modern web-based systems for Enterprise IT“ (Slides).

Stefan Tilkov hinterfragt alte Annahmen und stellt drei Thesen für eine Architecture 201x auf:

  1. Dinge klein schneiden
    • kleine, fokussierte Apps, siehe auch z.B. 12factor app
    • Isolation + Unabhängigkeit
    • Polyglote Programmierung möglich
  2. Teile integrieren, um ein Ganzes zu formen
    • Robuste System auf unzuverlässigen Netzwerken
    • Referenz auf „Circuit Braker„-Pattern aus dem „Release It!“ Buch mit Hinweis Hysterix und Finagle-Frameworks
  3. Effizienter Betrieb
    • Virtualisiertes OS als Container
    • automatisches Deployment
    • „You build it, you run it“

Wie immer von Stefan Tilkov ein guter Vortrag.

Keynote: Software Design in the 21st Century (Martin Fowler)

Siehe separaten Beitrag.

Komplexität oder Unffähigkeit (Gunter Dueck)

Ich kannte Dueck noch nicht. Ex-Querdenker bei IBM, jetzt im Ruhestand und Vortragsredner. Einfach mal auf Youtube schauen. Zum Beispiel das hier, ab ca. Stunde 1. (den Vortrag von der OOP2014 gibts anscheinend nicht online, war recht lustig).

Series Navigation<< Gehirnwäsche für FührungskräfteMartin Fowler: „Not just code monkeys“ >>