{"id":568,"date":"2014-04-07T21:59:28","date_gmt":"2014-04-07T19:59:28","guid":{"rendered":"http:\/\/www.epischel.de\/wordpress\/?p=568"},"modified":"2014-04-08T10:02:23","modified_gmt":"2014-04-08T08:02:23","slug":"oop-2014-zweiter-und-dritter-tag","status":"publish","type":"post","link":"https:\/\/www.epischel.de\/wordpress\/2014\/04\/oop-2014-zweiter-und-dritter-tag\/","title":{"rendered":"OOP 2014 – zweiter und dritter Tag"},"content":{"rendered":"
Dieser Eintrag ist Teil 6 von 7 in der Serie OOP 2014 Report<\/a><\/div><\/div><\/div>

Ich habe die Notizen und Anmerkungen zu den Vortr\u00e4gen, die ich an meinem zweiten Tag auf der OOP 2014 besucht habe, bereits in eigenen Blog-Posts verarbeitet:<\/p>\n

    \n
  1. Software-Evolution mit aim42 \u2013 Architecture Improvement Method<\/a><\/li>\n
  2. How to improve Estimates for Software: The #NoEstimates view<\/a><\/li>\n
  3. Imposing Rule-Based Architecture on Legacy Systems<\/a><\/li>\n
  4. Gehirnw\u00e4sche f\u00fcr F\u00fchrungskr\u00e4fte<\/a><\/li>\n<\/ol>\n

    Zu den Vortr\u00e4gen am dritten Tag:<\/p>\n

    Value Validated Architecture: Discover Your Architecture sans BDUF (Steve Holyer)<\/h2>\n

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

    Der Anfang klang ganz vielversprechend: brainstorming dar\u00fcber, was \u00fcberhaupt zur Architektur geh\u00f6rt. Dies erzeugt einen offenen Dialog und ein geteiltes Verst\u00e4ndnis der Beteiligten. Er sprach \u00fcber Constraints vs. Options und die Frage, welche Constraints Commitments und welche Options sind.<\/p>\n

    Dann verlor sich Steve etwas in seinem Vortrag. Das muss er noch ausbauen. Insofern am Schlu\u00df etwas entt\u00e4uschend. Folien gibt es online.<\/a><\/p>\n

    Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr (Michael Stal)<\/h2>\n

    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.<\/p>\n

    Wie sieht der Weg aus?<\/p>\n

      \n
    1. Profiling: welches Wissen brauche ich?<\/li>\n
    2. Reflection: welche L\u00fccken habe ich?<\/li>\n
    3. Doing: L\u00fccken schlie\u00dfen<\/li>\n<\/ol>\n

      Architecture 201x (Stefan Tilkov)<\/h2>\n

      Mit dem Untertitel „Lessons learned from modern web-based systems for Enterprise IT“ (Slides<\/a>).<\/p>\n

      Stefan Tilkov hinterfragt alte Annahmen und stellt drei Thesen f\u00fcr eine Architecture 201x auf:<\/p>\n

        \n
      1. Dinge klein schneiden\n