Dr. Matthias Naab

Matthias Naab ist Softwarearchitekt am Fraunhofer IESE und leitet seit 2015 die Abteilung „Architecture-Centric Engineering“. Seit 2010 verantwortet er die Weiterentwicklung von Architekturmethoden und die Beratung von Kunden aus der Wirtschaft. Er hat in zahlreichen Projekten in unterschiedlichsten Branchen Architekturen bewertet, Systeme verbessert und innovative Systeme mitgestaltet. Matthias Naab hält regelmäßig Tutorials zu Softwarearchitektur, unter anderem bei der Fraunhofer Academy und maßgeschneidert für Kunden. Erfahrungen aus der praktischen und pragmatischen Architekturarbeit teilt er gerne bei Konferenzen sowie im Buch „Pragmatic Evaluation of Software Architectures“.

Buch: Pragmatic Evaluation of Software Architectures

Im Juli erschien unser Buch „Pragmatic Evaluation of Software Architectures“ bei Springer.

Architekturbewertung leistet einen wesentlichen Beitrag zu Softwaresystemen mit hoher Qualität und zu fundierten Entscheidungen im gesamten Lebenszyklus eines Softwaresystems. Unser Buch stellt einen pramatischen Ansatz zur Architekturbewertung vor und präsentiert Erkenntnisse aus mehr als 75 Architekturbewertungsprojekten für Kunden aus unterschiedlichsten Branchen und Ländern, die wir in den letzten 10 Jahren durchgeführt haben. Wir zeigen neben der Methode auch zahlreiche Beispiele und Lessons Learned.

Architecture-Centric Integration Testing

Architecture design is responsible for dividing an overall system into manageable pieces, which can be independently worked on. The subsequent build and integration process is responsible for putting the pieces together to form intermediate stages and finally the overall system. Additionally, more and more integration of software systems of all types happen. Nevertheless, little attention is still paid to integration testing. We elaborate why architecting and integration testing should be highly connected activities and which best practices allow integration testing to be effective in practice.

Historisch gewachsen

Erfolgreiche Software lebt häufig viel länger als ursprünglich gedacht. Kontinuierliche Erweiterungen führen zu einem Zustand, den Praktiker gerne als „historisch gewachsen“ bezeichnen. Das äußert sich in inkonsistenter User Experience, leidender Qualität, steigenden Wartungskosten und mangelnder Innovationsfähigkeit.
Somit stellt sich fast jeder Softwarefirma irgendwann die Frage, wie die eigene Software erfolgreich renoviert werden kann und wie tiefgreifend der Eingriff werden muss oder darf, um auch in Zukunft die Geschäftsziele zu erreichen. Um die Weichen der Renovierung richtig zu stellen ist es notwendig, den tatsächlichen Zustand der Software genau zu analysieren, vor allem weil dieser erfahrungsgemäß deutlich von früheren Plänen und Dokumenten abweicht.