Zu Anfang dieses Kapitels wurde die Herangehensweise an die Interviews zur Informationsbe-schaffung vorgestellt. Dazu zählt unter anderem die Auswahl der Firmen. Wie gewünscht war es möglich Firmen mit unterschiedlichen Organisationstypen zu interviewen. Hierzu konnten für jeden Bereich (Projektgeschäft, Produktgeschäft, interne Entwicklung) unterschiedliche Interviewpartner gefunden werden. Die Inhalte der Interviews wurden anhand einer Sammlung von Themen ausgewählt. Aus diesen wurde ein Interviewleitfaden zusammengestellt. Der Leitfaden hat den Interviews eine Struktur gegeben. Er wurde aber nicht als fester Fragebogen eingesetzt. Dadurch konnte sich besser ein Gespräch entwickeln.
Die durchgeführten Interviews wurden im ersten Schritt einzeln ausgewertet. Zu diesem Zweck wurden hauptsächlich Besonderheiten hervorgehoben. Anschließend fand die Gesamtauswer-tung nach unterschiedlichen Oberkategorien statt. Hierzu wurde ein Kodierleitfaden, ähnlich zu einer qualitativen Inhaltsanalyse, erstellt. Die Punkte des Kodierleitfadens wurden in Ab-schnitten mit Oberkategorien analysiert. Hierzu wurden passende Zitate aus den Interviews
ausgewählt. Im ersten Schritt wurden allgemeine Diskussionsmöglichkeiten im Prozess vergli-chen. Dabei konnte festgestellt werden, dass viele der bereits aus Scrum bekannten Meetings eingesetzt werden. Als Ergänzung, fanden zum Teil zusätzliche Diskussionen statt. Diese waren in den Unternehmen sehr unterschiedlich aufgebaut. Das alle Unternehmen versuchen diesem Problem entgegenzuwirken macht deutlich, dass ihnen das Problem bewusst ist. Die starken Unterschiede in den Ansätzen zeigen aber auch, dass es noch kein richtiges Vorgehen gibt. Die Teams versuchen das Problem aus der Not zu lösen.
Im zweiten Schritt wurden die Aktionen während der Entwicklung verglichen. Diese haben das Ziel die Erosion gering zu halten. Hier waren sich die Interviewpartner größtenteils einig was z.B. Pair Programming und Code Reviews angeht. Auch wenn diese Maßnahmen in sehr unterschiedlichem Ausmaß eingesetzt wurden (z.B. dauerhaftes Pair Programming oder nur bei Problemen). Tests wurden von allen als sehr wichtiges Mittel angesehen, um eine gewisse Sicherheit beim Refaktorisieren zu gewährleisten. Es konnte aber auch festgestellt werden, dass dies schwieriger wird, wenn die Tests ebenfalls angepasst werden müssen. Eine ausführliche Prüfung der gesamten Anwendung fand nur in einem Unternehmen regelmäßig statt. In den anderen Unternehmen wurde nie die gesamte Anwendung auf eine vorhandene Erosion hin untersucht.
Die Meinungen zur Architektenrolle ähnelte sich teilweise. In der Hälfte der Teams war ein Architekt vorhanden. Alle waren sich dabei einig, dass der Architekt in erster Linie ein Ent-wickler sein sollte und deshalb auch keine Vorgaben oder ähnliches machen darf. Er kann eine technische Vertretung für das Team darstellen und darauf achten, dass eine Weiterentwicklung der Architektur stattfindet.
Der letzte verglichene Aspekt handelte von der Dokumentation. In der Mehrzahl der Teams wurde diese vernachlässigt. Teilweise wurden manuell Diagramme gepflegt. Bei diesen ist fraglich, wie effizient diese auf Dauer weitergepflegt werden können. Entscheidungen wurde ebenfalls selten notiert. Ein allgemeines Vorgehen zur Dokumentation konnte nicht identi-fiziert werden. Wenn eine Dokumentation erstellt wird ist es sehr wichtig die Gründe für eine Entscheidung zu notieren. Nur so kann dies zu einem anderem Zeitpunkt nachvollzogen werden.
Nach der Gesamtauswertung wurde eine Idee für ein neues Vorgehen vorgestellt. In diesem Vorgehen sind Informationen aus den Interviews eingeflossen. Die Aktivitäten während der Entwicklung, wie auch die Dokumentation wurde zum großen Teil außen vor gelassen.
Das Vorgehen führt einen neuen technischen Aspekt ein. Zuvor wurde rein auf Feature Basis gearbeitet. Dies erhöht die Komplexität des Vorgehens, weil ein zusätzliches Backlog einge-führt wurde. Eventuell könnte es helfen beide Backlogs zu einem zu vereinen. Spätestens im
Sprint-Backlog werden die Stories gleich behandelt. Durch die Trennung wird allerdings eine getrennte Priorisierung möglich. Die Priorisierung findet außerdem durch unterschiedliche Personen statt. Ansonsten ist vorstellbar, dass neue Funktionalitäten schnell eine höhere Priori-tät bekommen als eine Refaktorisierung. Durch die Meetings zum Review der Architektur und der Problemdiskussion wird zusätzliche Zeit benötigen. Problemdiskussionen finden allerdings bereits jetzt häufig statt, sind aber nicht in dem Vorgehen eingeplant. Außerdem ist vorstellbar, dass im gesamten Zeit eingespart wird. Es wird möglich notwendige Änderungen frühzeitig zu erkennen. Die Zeit müsste ansonsten in die Lösung der Probleme beim Auftreten investiert werden. Dies wird von der Feststellung bestätigt, dass eine hohe Erosion die Weiterentwicklung stark verlängern kann.
Das Vorgehen selbst wurde rein theoretisch entworfen. Eine praktische Evaluation fand nicht statt. Aus diesem Grund stellt es nur einen Vorschlag dar. Ob dieser Vorschlag praktisch einsetzbar ist muss ausführlich untersucht werden.
Die gesamte Auswertung konnte zeigen, dass die Unternehmen sich des Problems bewusst sind. Die unterschiedlichen Ansätze zeigen aber auch, dass dies eher ein Handeln aus der Not ist. Die Unternehmen haben erkannt, dass es für eine langlebige Software von starker Bedeutung ist eine gute Architektur zu entwickeln. Wie dies auf Dauer sichergestellt werden kann, ist aber ungewiss. Um dies zu lösen werden unterschiedliche Ansätze verfolgt. Diese sollen das eingesetzte Vorgehen ergänzen. Es wurde auch festgestellt, dass die Architektur kein starres Konstrukt darstellt, sondern wie die Anwendung stetig weiterentwickelt werden muss.
Das Team selbst stellt eine wichtige Komponente bei der Architekturentwicklung dar. Eine Strukturierung der Anwendung, die die Entwicklung durch mehrere Teams unterstützt, kann helfen. Die einzelnen Teams müssen dabei möglichst unabhängig arbeiten können. Gerade Ab-sprachen über Teamgrenzen hinweg sind schwierig und können starke Probleme verursachen.
Einige sehr interessante Informationen aus den Interviews sind nicht mit in die Auswertung eingeflossen. Diese sind nur in den Interviewberichten im Anhang vorhanden. Diese Informa-tionen standen meist nicht direkt mit der Architektur in Verbindung, können aber trotzdem wichtige Punkte für den Erfolg einer Entwicklung darstellen. Durch die Begrenzung auf einen Themenschwerpunkt wurde entschieden diese Aspekte hier nicht weiter zu beachten.
In diesem Kapitel wird die Arbeit zusammengefasst und ein allgemeines Fazit gezogen. Zusätz-lich wird ein Ausblick zur Fortführung des Themas gegeben. Dieser drückt aus, in welchen Bereichen weitere Untersuchungen notwendig sind und welche Bereiche in dieser Arbeit nicht betrachtet wurden.